coreutils: tsort background

1 
1 7.6.1 ‘tsort’: Background
1 -------------------------
1 
1 ‘tsort’ exists because very early versions of the Unix linker processed
1 an archive file exactly once, and in order.  As ‘ld’ read each object in
1 the archive, it decided whether it was needed in the program based on
1 whether it defined any symbols which were undefined at that point in the
1 link.
1 
1    This meant that dependencies within the archive had to be handled
1 specially.  For example, ‘scanf’ probably calls ‘read’.  That means that
1 in a single pass through an archive, it was important for ‘scanf.o’ to
1 appear before read.o, because otherwise a program which calls ‘scanf’
1 but not ‘read’ might end up with an unexpected unresolved reference to
1 ‘read’.
1 
1    The way to address this problem was to first generate a set of
1 dependencies of one object file on another.  This was done by a shell
1 script called ‘lorder’.  The GNU tools don’t provide a version of
1 lorder, as far as I know, but you can still find it in BSD
1 distributions.
1 
1    Then you ran ‘tsort’ over the ‘lorder’ output, and you used the
1 resulting sort to define the order in which you added objects to the
1 archive.
1 
1    This whole procedure has been obsolete since about 1980, because Unix
1 archives now contain a symbol table (traditionally built by ‘ranlib’,
1 now generally built by ‘ar’ itself), and the Unix linker uses the symbol
1 table to effectively make multiple passes over an archive file.
1 
1    Anyhow, that’s where tsort came from.  To solve an old problem with
1 the way the linker handled archive files, which has since been solved in
1 different ways.
1