On Friday 19 December 2008 20:30:19 Chris Wilson wrote:
> On Fri, 19 Dec 2008, Oliver Lange wrote:
> > Well, my understanding (without knowing how the linker actually
> > works), was that the linker should simply collect all arguments,
> > putting object filenames into one list of objects to link, all
> > libs into another list and then applying the remaining options to
> > the build. At least that would be my approach.. but what do i
> > know.. :P
Not very much, about the *normal* behaviour of linkers, on probably
the majority of UNIX, and UNIX-alike systems, it would seem ;-)
> If that was all that a linker did then it might as well be replaced
> with "cat". Its most important job is to find unresolved symbol
> references and resolve them by editing the object files. The GNU
> linker does this by looking through the list of objects that it has
> already seen, earlier on the command line. It does NOT build a
> dependency tree or look at later options when doing so.
> In the case of ELF, if it fails to resolve a dependency at link
> time then I believe that it will leave it unresolved, and the ELF
> loader will search the binary and its shared-object dependencies at
> run time to see if it can satisfy unresolved symbols.
Not exactly, (and I'm not at all sure of the precise details either).
I can say categorically that the rules are the same, no matter what
the system -- libraries must be specified *after* the object files
which refer to their members. ELF linkers may be more forgiving of
incorrect ordering, when the reference can be resolved from a shared
object library, but it is still technically an error to rely on this
feature; the ELF linker will be just as unforgiving of incorrectly
ordered static libraries, as is a PE linker, resulting in similar
undefined reference errors.
> The PE loader used by Windows DOES NOT do this.
> To be honest I suspect a problem with your build files rather than
> autotools or scons, as I've used autotools on projects on Windows
> and it has worked.
> > So you're saying that the autotools developers, the SCons
> > developers and all the others must update their build systems
> > because they all fail to humbly bow to the merciless
> > implementation quirks of some linkers out there...
No, not at all; he is saying that you, or the maintainers of the
package you are having trouble with, should learn to use those tools
> You need to find out where the problem actually is and file a bug
> report with them, not with us. I can't see this being fixed in
> MinGW as it's not our "fault", it's the PE loader in Windows.
It's not even the fault of the PE loader; it is misuse of the tools
used to maintain the project files. The autotools, in particular, do
work very well on MS-Windows as on GNU/Linux, and on countless other
platforms. (I'm sure the other tools mentioned do too; I simply have
no experience of them, on which to base any comment).
> > Hmmm, without seeking to annoy anyone, lets say i put the
> > 'main.o' object at the very end of the object file parameter
> > list, wouldnt a linker then have to fail because the previous
> > objects can't be linked since the main() function is still
> > undefined? Doesnt that mean that we all have to specify the
> > object file which contains the main() function first of all?
> No, because main() is actually referenced by a CRT file which is
> invisibly added to the end of the list of files to link, after your
Actually, it's called from the startup module, which is added to the
linking list *ahead* of the user specified object files. However,
that's mostly irrelevant anyway, because it isn't usual to define
main() in a library; it's more common to define it in an explicitly
specified object file, which will *always* be copied to the linked
> > And if i pass further linker options after the object files &
> > libs in the command line, wouldnt the linker ignore these options
> > for all object files stated somewhere earlier on? I mean, it all
> > sounds like as if the linker would actually start linking before
> > it has finished parsing the entire command line...
> Not necessarily, it's only the order of _object files_ on the
> command line that matters as far as I know.
Not at all. The order of object files, (or source files for that
matter), doesn't matter at all; every *object* file, whether it is
precompiled separately, or "on-the-fly", is copied in its entirety,
into the linked image. What does matter is the placement of
*libraries*, relative to the objects which reference them; (libraries
are not object files, but rather archive collections of multiple
object files). Object *members* from any library are only copied to
the link image if they define a symbol which was referenced, but not
yet defined, in any object file, (or by any selected member from
another library), which *precedes* that library on the command line,
(or is referenced by another member which has already been selected
from the *same* library).
> GNU getopt, and probably others, permute the command line as they
> parse it, moving all the options to the front.
BSD getopt does this too, but both provide a mechanism to disable that
feature; the linkers for both these systems do so, and in common with
the linkers of most UNIX systems, process arguments and options
strictly in the order given on the command line.
As Tor has already said, it is traditional to place a `-o exefile'
option early on the command line, although this one is perhaps less
fussy than any other. In general, you should place options *before*
any file to which they should apply, and libraries, (whether they are
specified by their full names or using the `-lname' pseudo-option
shorthand), *after* the object files referring to them, (and in the
case of interdependent libraries, the dependents must *precede* any