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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool