Re: [TUHS] ar libraries [was: Speaking commands [Was: Bell System Technical Journal archive]]

[Paul Winalski <paul.winalski@gmail.com>]

>On Wednesday, 18 July 2018 at 11:39:30 -0600, arnold@skeeve.com wrote:
>
> Archive files (static libraries) are alive and well and work just fine,
> on Linux and every other *nix that I know about. The format is even
> used on Windows for static libraries and for whatever you call them when
> linking dynamic libraries (they provide the symbols, but not the dll).

The symbol index for archives of object (.o) files was initially
optional and created by a separate program called ranlib.  At some
point ranlib seems to have been integrated into ar.  When did this
happen?

The version of ranlib from the mid-1980s had an implementation that
was a bit too simple-minded.  It indexed all symbols with N_EXT set
and a non-zero n_value field.  This means that Fortran common blocks
and C uninitialized file-scope variables ended up in the ranlib index
of the archive, which is wrong--such symbols should not trigger an
object file to be loaded.  ranlib should have filtered out symbols
that have N_UNDF set as well as N_EXT.  ld had a faulty work-around
for this problem.  When a symbol in a ranlib index triggered the
loading of a module, and ld found that the symbol was in fact a common
symbol, ld said "oops" and unloaded the module.  But by this time ld
had already maximized the sizes of all common symbols, and that didn't
get backed out.  The result is that common symbols were allocated
space in .bss based on the largest size that ld saw while scanning
archives, NOT the largest size actually participating in the link.

There was in fact a bug in stdio that relied on this (mis-)feature.
It drove me bonkers when I ported the VMS linker to Ultrix.

-Paul W.