From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-07-14 10:27:22
Markus Schöpflin wrote:
> I just discovered that I cannot prelink a dynamic library produced by bbv1.
> The system I tried this on was RHEL 3. The error message I got was:
> prelink: ... section file offsets not monotonically increasing
> After a lot of head scratching, I decided to disable the use of objcopy in
> gcc-tools.jam, et voila, now prelink works.
> This leaves me wondering why objcopy is used at all. I found some reference
> on this ML to a linker performance problem that this should fix, but I
> wasn't successful in digging up more info.
As the comment on the gcc-tools.jam says:
# used to manipulate the object files produced by GCC to
# prevent the merging of debug symbols (which happens to be n^2 slow)
flags gcc .OBJCOPY : [ GLOB $(GCC_BIN_DIRECTORY) $(PATH) : objcopy ] ;
At the time of me adding that the GNU linker had a "bug" that because of
the large number of debug symbols that GCC produces when compiling C++
code would slow down the link step considerable. Here's what I said
about it on change itself:
"Add objcopy post-processing of compiled .o files to remove read-only
status of debug strings. This is to prevent the linker from running the
constant string merge algorithm which is very slow (n^2). The problem is
most obvious when dealing with template C++ code which produces large
numbers of debug symbols."
> Is objcopy still needed?
It may be that the "bug" in the linker is no longer there, and I
remember some discussion on the binutils crowd about it getting
addressed. So it's possible it's no longer needed. But that would apply
to new distributions as old one would still use the slower binutils.
> I don't seem to get any noticable speed benefit
> when it's used.
Try linking many, more than 10, object files that all use template
heavily. Of course it could be that your system has a binutils that
doesn't have the "bug" ;-)
> Is there some way to disable the use of objcopy, besides
> creating a new tools file?
Hm, it doesn't look like it :-( It hadn't come up until now, it's easy
enough to check for some option (--no-objcopy) on the invocation. Of
course I wonder why is it that the link doesn't work for you given that
all BBv1 does with objcopy is remove the 'readonly' flag from debug_str
So one question I have; What is the version of binutils you are using?
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk