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