maumg@warwick.ac.uk (Pop Mobility Freak) (04/23/91)
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.
PMFjohn@acorn.co.uk (John Bowler) (04/30/91)
In article <P&?_*P&@warwick.ac.uk> maumg@warwick.ac.uk (Pop Mobility Freak) writes: >I am not really sure whether the linker should search previous libraries to >try and match unmatched references (do Un*x compilers do this?). No. Order of specification of libraries (and order wrt simple object modules) is almost always important. I have a feeling that it might not matter under VMS but I can't remember for sure :-) >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. An alternative strategy is to repeat the libraries on the command line (I think this works with link, it certainly works with ld on UN*X systems). In some cases altering the order can alter the program produced - if, for example, two libraries duplicate the same function definition. John Bowler (jbowler@acorn.co.uk)