Incremental linking

[Richard Henderson]

On Thu, Apr 09, 1998 at 01:46:28PM -0500, Dave Taylor wrote:
> 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?

No.  The misunderstanding here is that ld is not doing "incremental linking,"
but rather "relocatable linking".  Ie you get a new object file that is in
no way different from any other object file.

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

Depending on prevailing conditions, `ld --no-keep-memory' may help.

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

With Linux after say 1.2, a ramdrive probably won't help, and may even
hurt.  The page cache in 2.0 is really fairly effective.

> We've also tried creating shared libraries which I guess basically defers
> the link until each module is needed at execution time.

Yes.  

The trade-off here is that if you use PIC code, you loose a register,
and if non-PIC code, startup time can be much longer due to the number
of dynamic relocations.  Furthermore, the fact that you're now going
through a PLT for calls between DSOs, some of the instruction prefetch
mechanisms of the ppro core are thwarted. 

All-in-all probably not a great idea to use them carelessly.


r~