Re: g++ isn't link an indirectly used .a library

[Brian Dessent <brian at dessent dot net>]

Michael Darling wrote:

> I'm not sure if this is an issue with my KDevelop settings, or rather
> if it is a g++ problem. If it's a g++ problem, I'm wondering if

First of all, realise that g++ doesn't have any say in the matter.  g++
invokes collect2 which invokes the linker (ld), and it's the linker that
issues the error.  g++ is just a driver to invoke the linker with some
extra options, it doesn't actually do any linking.  (But you should
always link by calling the driver and not 'ld' precisely because those
extra options that the driver adds behind the scenes are vital.)

The second thing to realize is that the linker scans each object/archive
incrementally in the order specified on the command line from left to
right.  When scanning an archive (.a), if any objects in that archive
contain symbols that satisfy references that the linker has seen so far
but not yet resolved, those objects get copied from the archive into the
output.  Any remaining objects in the archive are ignored.  In other
words, when the linker examines an archive it can only use it to resolve
symbols that it knows are necessary at that point in the process.  If
some object or library later down the line refers to a symbol in one of
the objects that was not copied, it will result in an undefined
reference because the linker only examines each argument once in the
order specified.

The implication of this is that you must supply arguments in the correct
order of dependency.  Furthermore, if there is a circular dependency,
you must specify some arguments twice, e.g. if liba and libb mutally
refer to symbols in each other then you would need to specify something
like "liba.a libb.a liba.a".

The linker also has alternative ways of dealing with the problem, such
as the --start-group and --end-group options, or the --whole-archive
option.  See the ld manpage for details.  Note also that since these are
linker options, you must use -Wl when specifying them to g++ so that the
driver will pass them through to the linker rather than trying to
interpret them as compiler options, which they are not.  For example,
instead of "../../liba/liba.a ../../libb/libb.a" you might need "-Wl,-(
../../liba/liba.a ../../libb/libb.a -Wl,-)" to tell the linker that
there's a circular dependency between the two.

I should also note that as stated (app only depends on liba, and liba
only depends on libb) that your command:

> g++ -g -O2 -o app app.o -L/usr/lib/mysql ../../liba/liba.a
> ../../libb/libb.a -lmysqlclient
> ../../liba/liba.a(liba.o): In function `@@@`:
> liba.cpp:@: undefined reference to `libb::@@@`
> collect2: ld returned 1 exit status

...seems correct and should work.  But the fact that it does not
suggests that there is some additional circular dependency that exists
between liba and libb that you're not aware of, perhaps in something
unobvious like a constructor for a static object.

If you use the linker's --verbose option (i.e. g++ -Wl,--verbose) it
will show you explicitly the order in which archives and objects are
processed, and which objects get included into the final link. 
Hopefully you can compare the verbose output from the working and the
non-working case and see the nature of the liba<->libb interdependency.

> If I change app's main() from:
> libAClass goingToUseThis();
> 
> to:
> libBClass hack();
> libAClass goingToUseThis();
> 
> Then it links fine.

When you do this, ld sees a reference to libBClass at the point where it
scans app.o, which is apparently sufficiently early enough in the
process to cause it to link the necessary objects from libb.a when it is
later encountered.

> Is there a way for me to forces g++ to actually link libb.a, when app
> is only directly using liba.a? I'm suprised g++ can't figure out that
> libb.a really has to be linked since it's being told to do so through
> the arguments given.  Then again, maybe I'm missing something
> simple...

You need to have a better mental model of how linking works.  It's not a
yes/no "should I include this library or not" kind of deal (and it's not
even g++ that is at work here.)  It's more like "I will scan this
archive and from it copy any objects that satisfy undefined references
that I've encountered so far" -- the key words being "so far", as it's
impossible for the linker to know beforehand what it will need out of a
given archive unless it's already scanned every object that might
reference something in that archive.

The reason that the linker cannot simply consider everything at once in
whole is performance.  It might not matter on small projects but on
medium or large sized links it would be prohibitively slow if it worked
that way.  I suppose you could force it to operate that way by grouping
all arguments into one giant --begin-group/--end-group, but I think you
would experience a significant increase in link time for anything of
size.

> I'm using versions all included in the default RHEL5 yum repositories.
> KDevelop 3.5.1, g++ 4.1.2, automake 1.9.6, autoconf 2.59.

Note that the linker is not part of gcc.  On GNU/Linux systems the
linker is part of the binutils package.  Also note that in some
circumstances and on some platforms, the rules are different, e.g. with
shared libraries on GNU/Linux the order given on the link command
doesn't matter because the symbols are resolved at run-time anyway as
opposed to link-time.  But that shouldn't be license to ignore proper
dependency-ordering on the link command, since it does matter even for
shared libraries on other platforms, and it always matters for static
libraries (.a archives.)

Brian