Re: Why does linker fail to resolve dependencies within the same .a file?

[Nick Clifton <nickc at redhat dot com>]

Hi Christian,

  [I have restored the CC to gcc@gcc.gnu.org as there may be other 
people interested in this discussion].

> >    foo.o -lbar baz.o -lbar
> >
> > The second "-lbar" is only needed if baz.o includes references to
> > symbols that are defined in libbar.a which will not be pulled in when
> > resolving the references made by foo.o.
>
> I'm not so sure that's true, because someone said that putting "bar.a"
> on the linker command line is pretty much identical in effect to
> listing, on the command line, the files that got bundled up into
> bar.a.  So if bar.a is made up of x.o, y.o and z.o, and z.o contains a
> function that depends on a function in x.o, then I really do need to
> list bar.a twice in order to resolve that dependency. No?

No.  :-)

A library is not, quite, the same thing as a bunch of object files.  For 
one thing the linker *will* repeatedly search a library until no more 
undefined symbols can be resolved.  So in your example x.o will be 
pulled into the link because it is needed to resolve a reference in z.o 
(which is presumably needed to resolve a reference from an object file 
earlier on in the linker command line).

This is all described in the linker documentation as well.  Have a look 
at the description of the linker command line option --start-group.


> I pasted an irrelevant example by accident, but I really am seeing the
> problem in question (I think).  Here's the link command and my first
> error message from it:
>
> /usr/bin/c++      -fPIC "CMakeFiles/simpleIO.dir/main_IO.o"   -o
> simpleIO -rdynamic
> -L/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++ -lGL
> -lglut -Wl,-Bstatic -luriVision -luriVision -Wl,-Bdynamic
> -Wl,-rpath,/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++

> /home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a(ImageReader.o): 
> In function `uriVideoSources::ImageReader::getFrame(bool,
> uriBase::RasterImage*)':
> ImageReader.cpp:(.text+0x90): undefined reference to
> `uriVideoSources::ImageReader_gen::getFrame_(bool,
> uriBase::RasterImage*)'
>
> and here's the (hopefully) telling nm/grep statement:
>
> cjc@peace:~$ nm --demangle
> /home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a 
>
> | grep "uriVideoSources::ImageReader_gen::getFrame"
>         U uriVideoSources::ImageReader_gen::getFrame_(bool)
>         U uriVideoSources::ImageReader_gen::getFrame_(bool,
> uriBase::RasterImage*)

Well this tells me that ...getFrame_(bool.uriBase::RasterImage*) is an 
*undefined* symbol referenced from inside liburiVision.a.  (Hence the 
'U' attribute as displayed by nm).  Hence the linker is correct in 
complaining that it cannot resolve the reference and hence you do need 
to tell the linker where to find this symbol.

Where do you think the ...getFrame_(bool.uriBase::RasterImage*) symbol 
is defined ?

Cheers
  Nick