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

[John P. Linderman]

A few long-dormant brain cells woke up and convinced me that ranlib was
done by Peter Weinberger. Perhaps Doug or Peter can confirm or refute the
memory.

On Thu, Jul 19, 2018 at 11:29 AM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> >On Wednesday, 18 July 2018 at 11:39:30 -0600, arnold at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180719/9283c1b3/attachment.html>