Re: Trivial program size inflation

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Can't say I understand why ld(1) behaves this way, though.  (I'm
> pretty sure I ran ranlib too.)  It should've noticed _all_ the
> functions in the supplied archive, right?

Not if there were no unsatisfied references to them at the time it gets
to that .a in the list.  With .a archives, the unit of inclusion in the
link is the object file within the archive, in contrast to .so
archives, where it's all or nothing.  Once it's done bringing in
everything from libgnumalloc.a (to use the example I cited) that was
undefined at that point in the link (given how libgnumalloc keeps
calloc off in a file of its own, that did not include any .o defining
calloc), libgnumalloc.a is no longer available to resolve undefined
references.  Then, when a .o file from libc.a refers to calloc, a
symbol that isn't yet present, the only version available to satisfy
the reference is libc's own implementation.

However, depending on the details of how the dynamic linker and the .so
builder work, it may not matter.  If we build it dynamic and use
-lgnumalloc, yes, it will bring in all of libgnumalloc.so, but it will
also bring in all of libc.so.  Whether it will actually work depends on
whether libc referring to a symbol defined elsewhere in libc but also
defined in a different .so already included resolves to the libc
version or the other library's version.  (Or, if that condition is an
error, it may error instead of even trying to work.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B