[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bob Friesenhahn
Subject: Re: lazy symbol binding failed - on MacOSX 10.7 and 10.8
Date: Sun, 17 Mar 2013 13:41:33 -0500 (CDT)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

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 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

./ 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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]