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

Ian Lance Taylor iant@google.com
Wed Feb 28 15:24:00 GMT 2007

"Christian Convey" <christian.convey@gmail.com> 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 gcc-help@gcc.gnu.org, not on gcc@gcc.gnu.org.
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

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:
> 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*)

As answered elsewhere, 'U' means an undefined reference.


More information about the Gcc mailing list