Re: library search test fails, please help

[Keith Marshall]

On Monday 23 February 2009 01:39:52 Allan Caffee wrote:
> Indeed I tried a very similiar scenario using gcc 4.2.4 on Ubuntu
> (with a static library) and had the same problem.

Unsurprising, since you have specified your g++ command incorrectly.

> Was the error similiar to your original post?  A linker error?  We
> must be missing something pretty obvious here.

You are -- *user* error!  You gave an example of g++ usage, which was 
effectively equivalent to:

  $ g++ -L /path/to/my/libs -lbar foo.cpp

This is just plain wrong.  You are asking ld (indirectly) to search in 
libbar.a, for any symbols to satisfy any dependencies it has already 
identified, AT THE TIME WHEN IT SCANS THE LIBRARY.  Since arguments 
to ld are processed in strictly left to right order, there are no 
such symbol dependencies at this time; (the dependencies will not be 
discovered until *after* foo.cpp has been processed, and that happens 
too late to fetch in *anything* from libbar.a, so libbar.a becomes 
effectively unused, in this scenario.  You *must* specify your source 
or simple object files, *before* any library you wish to search for 
symbols used by them.  Thus, the correct usage is:

  $ g++ foo.cpp -L /path/to/my/libs -lbar

This illustrates a very common user error, and many users complain 
that ld must be broken, when they commit it.  This is particularly 
true of users coming from GNU/Linux to MS-Win32 development, because 
they have developed a *bad* *habit* on GNU/Linux; when linking to a 
*shared* object library, the misplacement of the library spec may be 
forgiven by the ELF gnu-ld, but it is still an error, and it will be 
severely punished by the PE-COFF gnu-ld on MS-Win32.  In the case of 
*static* libraries, this error will also be punished on GNU/Linux, 
just as it is on MS-Win32.

On the gcc, or g++ command line, libraries *must* *always* be 
specified *after* the source or object files which refer to them.

-- 

Regards,
Keith.