This message (http://lists.gnu.org/archive/html/libtool/2004-12/msg00263.html)
is left without answer. I am quite stuck currently. It seems
to me that it is due to a CVS libtool bug on Darwin, but I have
received no confirmation.
The original message includes a test case.
Thanks!
I'm not sure I understand correctly what -static means for programs. My understanding is that during the build, libraries against which the program is linked are statically linked if there are not installed *now*. Reading the documentation, it is somewhat unclear to me whether it refers to libraries that are installed or not *now* (the present), or meant to be installed or not (the future).
`-static' If OUTPUT-FILE is a program, then do not link it against any uninstalled shared libtool libraries.
My wondering comes from the fact that the attached tarball (to
bootstrap via autoreconf -fvi) does not link statically on Darwin when the
top level Makefile.am builds a lib_LTLIBRARIES (*to be installed*, but not
yet installed). It builds, but the resulting binary is incomplete:
sulaco% file hw
hw: Mach-O executable ppc
sulaco% otool -L hw
hw:
/usr/local/lib/libhw.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)
sulaco% ./hw
dyld: ./hw can't open library: /usr/local/lib/libhw.0.dylib (No such file or directory, errno = 2)
zsh: trace trap ./hw
(Isn't lilbtool expected to build a wrapper script in such a case?)
When I replace
lib_LTLIBRARIES = libhw.la
with
noinst_LTLIBRARIES = libhw.la
then it works properly.
Note that on my Linux box, both work and link libhw statically into hw. Note also that AC_DISABLE_STATIC is specified.
This is with CVS Libtool. BTW, thanks for the multiple files with the same name within a single archive fix :)
And please, keep me in CC.
<c++-libtool-swig-python-0.01a.tar.gz>
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool