Incremental linking

[Dave Taylor]

I've been noticing the "-r" command in ld for some time now, and as our
project is almost at 1000 files and takes a solid 30 seconds to link with
debugging symbols, I've been lusting to figure out how incremental linking
works.

I grok that -r generates an output file which in turn can be used to link
with, and I've gotten that to work. 

However, the desired use for this relinkable file is to be able to say
something like:

gcc relinkable.o module1.o module2.o ... -o my_proggy

Where module1.o and module2.o may already be in the relinkable.o file, but
because they've been specified on the command line, the symbols in those
module*.o files override the symbols in the relinkable.o file.  Is there a
way to get ld to behave this way?  Or was that half of the incremental
linking feature never implemented?  Because when I try that, it complains
that there are duplicate symbols and is clearly not trying to override the
old symbols. 

I'm interested in any alternatives you know of to shorten the link time.

A big problem seems to be that the output file is a whopping 12Mb, and the
*.o files take up a healthy 50Mb themselves.  This stuff is partially
bloated because of the size of the debugging info added by -g.  We've
noticed that MSVC puts the debugging symbols in a seperate file.  Perhaps
they did this to speed up linking? 

We're using Linux, and we've already tried using RAM drives and getting
lots of RAM.  Unfortunately, we don't entirely grok how to allocate a
certain amt of RAM to the ramdrive.  The technique shown to us was to
mke2fs on /dev/ram1, specifying how many blocks, and then mounting the
/dev/ram1 file.  Doing this made my system unstable, and interestingly, I
couldn't umount it.

We've also tried creating shared libraries which I guess basically defers
the link until each module is needed at execution time.  This speeds
things up rather a lot, but we noticed that gdb doesn't debug shared
libraries very well for us.  If you step into a function that's in a
shared library, instead of popping in, it gets confused about what line
number you're on, or it'll start stepping through what looks like
hash-table glue code.  Not being able to debug hurts.

We're using egcs 1.0.2, and we make extensive use of C++.  I've heard
rumors that libg++ isn't terribly well-tested for interoperability with
other libs.. ?

Thanks for any comments or suggestions.  My e-mail is ddt@crack.com.

	=-ddt->

---------
Dave Taylor, Owner
Crack dot Com, Inc.  http://crack.com