This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: incremental ld ?
- To: Steve Chamberlain <sac at transmeta dot com>
- Subject: Re: incremental ld ?
- From: mahamud at cs dot cmu dot edu
- Date: Sat, 15 Jul 2000 19:14:23 -0400 (EDT)
- CC: binutils at sources dot redhat dot com
- References: <mahamud@marr.ius.cs.cmu.edu><200007151013.DAA22014@neosilicon.transmeta.com><20000715154748.89DEE8CB2F@vole.transmeta.com>
thanx for the prompt reply!
>> Let me guess - it's a large g++ project compiled with debygging
>> ? I had something like this last year. I fixed it by sending
yes, a module for the mozilla browser project.
>> in a patch to ld which did better hashing for the debugging
>> info (which halved the time) and compiling fewer files with
i assume that this patch has been incorporated into the current ld.
>> debugging turned on (which got the time to somewhere just
>> beyond painful).
i did'nt think of this before. i have tried it now, it cuts down on the space
a lot - from ~50MB to ~14MB, but it shaved off only ~2 min from the
12 min link time.
>> (My next step would have been to split the binary into
>> different shared objects)
the code is divided into lots of shared objects,
but the problem i am facing is while creating another shared object
from a bunch of objects and other shared objects.
most of the object files are not modified. if i wanted to create a
final executable, then i would use your suggestion and create
a new shared object from the object files that don't get modified
and use that along with other shared objects and the
object files that get modified to create the executable.
i have tried an alternative suggested by the ld man page.
i used 'ld -Ur' to create a relocatable file from all the object files
that don't get modified. the man page claims that further linking should be
faster with such a relinkable object file. i then create the shared
object i want with this relinkable object file
along with the modified object files (as
well as other shared objects). Surprisingly things get worse, ~20 min
vs. 12 min. without 'ld -Ur'. am i doing something wrong ?
while on this topic of relinkable objects, i would like to ask why
i cannot link in shared objects with the 'ld -Ur' option ?
i can only link in these shared objects while creating the final
shared object using a normal ld. is this a limitation of the current
implementation of gnu ld or is it fundamentally not possible (i am not
a compiler/linker expert). i would think that if it was possible
to link in shared objects with 'ld -Ur' then a lot more symbols could
get resolved upfront, thus avoiding having to resolve
these symbols while creating the final shared object.
any comments and help would be appreciated.
thanx
- shyjan