Re: [jamboost] Use of objcopy prevents prelink to work on Linux

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 
sections.

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