Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!warwick!maumg
From: maumg@warwick.ac.uk (Pop Mobility Freak)
Newsgroups: comp.sys.acorn
Subject: The linker
Message-ID: <P&?_*P&@warwick.ac.uk>
Date: 22 Apr 91 18:27:56 GMT
Sender: news@warwick.ac.uk (Network news)
Organization: Computing Services, Warwick University, UK
Lines: 45
Nntp-Posting-Host: orchid

As you may have seen me mention when trying to compile Paul Moore's port of
the Gnu utilites that it seemed that the mktime function was not in the
AnsiLib for some reason but was in Stubs. Infact this is not the case, the
mktime function is in AnsiLib. So what lead me to believe that it wasn't I
hear you ask.

Well, if the command

        link fubar.o somemore.o etcetera.o <C$Libroot>.stubs.o utils.o
(there may be some -l's about I cannot remember)

(utils.o is a library file (ie a collection of object files) which uses
mktime)

is executed then the everything works fine. But if the command

        link fubar.o somemore.o etcetera.o <C$Libroot>.ansilib.o utils.o
(ditto about -l's)

is executed the linking failed because a reference to mktime could not be
matched. The reason for this is due to the way the linker works. After all
the object files (fubar, somemore and etcetera) have been linked the
AnsiLib is searched to try and match any references not already matched.
When no more references can be matched the utils library is searched to try
and match any more unmatched references. However because the utils library
needs mktime (which is in the AnsiLib) it produces an unmatched reference to
mktime. This reference never gets matched as the AnsiLib is not searched
again. The simple way to fix this (take note Paul or Graham) is to reverse
the order of the libraries in the command so that utils is searched first
(which produces an unmatched reference to mktime) and AnsiLib is searched
second (which matches the reference to mktime).

Everything worked with stubs though because stubs is an object file and so
every function within it is automatically included in the executable.

I am not really sure whether the linker should search previous libraries to
try and match unmatched references (do Un*x compilers do this?).

The only thing which would not compile (by changing the order of the libraries
on the command line) is two libraries each of which has external references
into the other. If this was the case though the two library files should be
merged into one which would naturally solve the problem. A loop of three (ie
A uses B, B uses C, C uses A) or more libraries could have a similar effect.

PMF