Linking issues [ was: Re: [HOpenGL] Re: ANNOUNCE: HOpenGL 1.05 released]

[Glynn Clements]

Sven Panne wrote:

> > [...] You should be able to work around the problem by adding -lXxf86vm to
> > the link command, but it has to come *after* the -lfreeglut-1.3
> > switch.
> 
> Glad to hear this. :-) Some people on this mailing list had linking
> troubles, especially with GHCi and GLUT/GLU/GL. AFAIK there are
> basically two kinds of platforms: Ones where the relative order of
> libraries on the linker commandline does not matter and ones where
> you have to mention a library B used by a library A after it, i.e. 
> in the order "-lA -lB". Solaris falls in this category, see e.g. my
> patches submitted to the Mesa project:
> 
>     http://sourceforge.net/tracker/index.php?func=detail&aid=544638&group_id=3&atid=300003
>     http://cvs.sourceforge.net/viewcvs.py/mesa3d/Mesa/demos/Makefile.am?r1=1.29&r2=1.30
> 
> If the GLUT package doesn't work with GHCi on some platforms, the
> exact circumstances would be interesting. On x86 Linux the order
> "-lglut -lGLU -lGL <some X11 libs>" works perfectly. Perhaps there
> are some dlopen() incompatibilities between different platforms. Any
> experts in this area on this list?

I'm no expert, but I'll add the following:

The ordering is usually important for static libraries; on some
platforms, it may also be important for shared libraries, but that is
less common.

A static library is simply an archive of object files (similar to a
zip file, but simpler), possibly with the addition of an index
(usually generated by ranlib). When a static library is used in the
link command, the linker only includes those object files which are
actually required to satisfy unresolved symbols.

If that the libraries are processed in the order listed on the command
line, only unresolved symbols from the object and library files which
have been processed up to that point ar considered. Any unresolved
symbols in libraries which appear after a given static library won't
be considered in determining which object files to use from the static
library.

[Aside: there appears to be a "feature" in the MacOS X linker (at
least, up to and including that in 10.2), namely that it only
considers symbols which correspond to functions (not variables) when
determining which of a library's object files are required. If a
library member is only required for the variables which it defines, it
won't be included in the link.]

For maximum reliability, the libraries should appear in the link
command in order of their depth in the dependency tree; each library
should appear after any libraries which require it. In the event of
circular dependencies (which are generally considered bad design, but
occasionally occur), it may be necessary to list a library more than
once. Even when this isn't necessary, it won't do any harm.

-- 
Glynn Clements <glynn.clements at virgin.net>