Re: lazy symbol binding failed - on MacOSX 10.7 and 10.8

[Bob Friesenhahn]

On Sun, 17 Mar 2013, Peter Johansson wrote:

> Hi libtoolers,
>
> I've encontered a problem on newer OSX (10.7 and 10.8) when mixing a static 
> library (libfoo) and a dynamic library (libbar). The dynamic library is 
> created with libtool so there is a libbar.la file whereas for the static 
> library there is no .la file. Code in libbar uses libfoo but although the 
> binary is created linking with '-lbar -lfoo' the function is not found by the 
> dynamic loader and  instead we get an error message:
>
> libtool: link: g++ -g -O2 -o .libs/baz baz.o -Wl,-bind_at_load \
>    ../bar/.libs/libbar.dylib ../foo/libfoo.a
> dyld: lazy symbol binding failed: Symbol not found: _foo_version
>  Referenced from: /Users/jari/projects/yat/bar/.libs/libbar.0.dylib
>  Expected in: flat namespace
>
> dyld: Symbol not found: _foo_version
>  Referenced from: /Users/jari/projects/yat/bar/.libs/libbar.0.dylib
>  Expected in: flat namespace
>
> ./link_test.sh: line 147: 80434 Trace/BPT trap: 5       ./baz
>
>
> Has anyone seen anything like this? Is this a bug in the apple linker or are 
> we using libtool incorrectly? I found this old thread from Peter O'Gorman

It is not portable, safe, or advisable to link a shared library with a 
static library.  Due to this, libtool does not apply .a files while it 
is linking a shared library.  Usually it warns and provides advice 
when it skips applying the library.  It is willing to apply the .a 
files while it is linking an executable which depends on the shared 
library.

There is special case of archive library known as a "convenience 
library" which libtool will build with a .a extension, but since 
libtool assures that objects in convenience libraries are built with 
options suitable for a shared library (e.g. PIC), and because libtool 
extracts the .o files prior to linking, libtool is willing to use a .a 
file in that very special case.

When using libtool, you have the option to build this other library as 
a shared library, or you can allow your shared library to have many 
unresolved externals and resolve them by adding this other library to 
the link when a dependent executable is linked.  It is common for 
shared libraries to have unresolved externals on many popular systems, 
but usually these are related to implicitly-added operating system 
run-time libraries and it is impolite to make users explicitly add 
more libraries for a successful link (but libtool can help with that).

If you list all depedendency libraries while linking both libraries 
and dependent executables then normally the exectuable will link 
successfully since libtool will include the library just once while 
linking the executable.  This behavior (including all dependencies in 
the link) is necessary for WIN32 and (as far as I am aware) on IBM's 
AIX.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/