"Christian Convey" <[EMAIL PROTECTED]> writes: > 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?
This also belongs on [EMAIL PROTECTED], not on [EMAIL PROTECTED] Please take any followups to gcc-help. It is not the case that listing a .a file is identical to listing the bundle of .o files in the .a file. Most obviously, .o files are only pulled out of the .a file if they are needed. Moreover, if you explicitly put x.o on the command line, it is always included in the link. If z.o refers to a symbol defined in x.o, the linker handles that as expected; you certainly don't need to add x.o again. Similarly, if one .o in a .a, such that the .o is included in the link, refers to another .o in the same .a, the linker handles that by pulling the second .o into the link as well. > 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*) As answered elsewhere, 'U' means an undefined reference. Ian
