Incremental linking

[Jeffrey A Law]

  In message < Pine.LNX.3.96.980409133155.9469B-100000@crack.crack.com >you write:
  > I grok that -r generates an output file which in turn can be used to link
  > with, and I've gotten that to work. 
Right.  Basically it just takes all the given .o files and makes one
big .o file from them.  Generally that's all that happens -- ie no
symbol resolution is done by most linkers for -r.


  > 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?
ld doesn't work that way.

What you want is shared libraries :-)

  > 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? 
Quite possible.  Dealing with debug symbols is a significant amount
of time for the linker.  These days it's mostly the IO costs I 
suspect (contrast to a.out style stabs which are computationally
expensive as well as IO expensive).  You aren't using a.out are you?!?

  > 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.
Report them as bugs to the gdb folks :-)   Odds are gdb just needs
some code to analyze the x86 shared library sequences.  It's too bad
there's no standard way for the linker to describe the stub code to
the debugger....  

jeff