Re: Problems combining static in shared libraries
Thanks for the quick reaction. On Thu, Nov 15, 2007 at 08:29:34PM +0100, Ralf Wildenhues wrote: > Confirmed. Yuck. You should be able to work around it if you drop the > AC_DISABLE_SHARED and instead add > libbar_la_LDFLAGS = -static That work-around seems to work for me. skimo ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Problems combining static in shared libraries
Hello Sven, Replying to this issue only for now: * Sven Verdoolaege wrote on Thu, Nov 15, 2007 at 10:48:40AM CET: > > In any case, I "solved" this problem by specifying AC_DISABLE_SHARED. > However, my own library not only depends on a static library > but also on some other libtool libraries (not configured > with AC_DISABLE_SHARED) and that also produces incorrect results. Where the "other libtool libraries" are also _uninstalled_ (important detail!), thus live in a subpackage (or sibling package in a package hierarchy). > In particular, if you configure with AC_DISABLE_SHARED > and have an application "main" that (also) depends on some other > yet uninstalled libtool library then > the application will be linked against the .so version of > the library, but libtool will not create a .libs/main or .libs/lt-main > and the installed binary will refer to the uninstalled libtool > library rather than the installed libtool library. Confirmed. Yuck. You should be able to work around it if you drop the AC_DISABLE_SHARED and instead add libbar_la_LDFLAGS = -static to the toplevel Makefile.am. At least it looks like that does TRT. So that means in a package hierarchy like in your example (thanks!), one cannot currently have partly AC_DISABLE_SHARED and partly not. Ouch. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Problems combining static in shared libraries
I have reported a problem before when compiling a shared library that depends on a static library. See http://lists.gnu.org/archive/html/libtool/2005-06/msg00170.html AFAIK, this problem has not been solved yet. In any case, I "solved" this problem by specifying AC_DISABLE_SHARED. However, my own library not only depends on a static library but also on some other libtool libraries (not configured with AC_DISABLE_SHARED) and that also produces incorrect results. In particular, if you configure with AC_DISABLE_SHARED and have an application "main" that (also) depends on some other yet uninstalled libtool library then the application will be linked against the .so version of the library, but libtool will not create a .libs/main or .libs/lt-main and the installed binary will refer to the uninstalled libtool library rather than the installed libtool library. To reproduce, untar the attached tar file and do ./autogen.sh && ./configure && make Please advise on how to solve this conundrum. skimo static-shared-test.tar.gz Description: application/gunzip ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
