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:
[EMAIL PROTECTED]:~$ 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
