Re: Disable --whole-archive when using convenience archives
[ http://thread.gmane.org/gmane.comp.gnu.libtool.general/10586 ] Hello Alon, * Alon Bar-Lev wrote on Mon, Mar 22, 2010 at 08:00:19PM CET: It is find if you don't want to solve this, but please acknowledge that you don't. So far I did not get any response regarding this issue. I'm really sorry I dropped the ball on this for so long. /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la liba.la ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la libb.la ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' I can reproduce this issue with your example tarball, thanks. At a glance it looks like a libtool bug to me, but I'm not sure what would be the right thing to do (without setting deplib check to pass_all for mingw). Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Hello Ralf, It is find if you don't want to solve this, but please acknowledge that you don't. So far I did not get any response regarding this issue. When using: AM_CFLAGS = $(PCAP_CFLAGS) -prefer-pic AM_LDFLAGS = -rpath $(libdir) -static In order to make whole-archive go away, it works in *NIX but not in Windows. In order to fix it I need to modify libtool: elif test $build_libtool_libs = yes; then # Not a shared library - if test $deplibs_check_method != pass_all; then +if false test $deplibs_check_method != pass_all; then Any chance this will be solved properly? Thanks, Alon. On Mon, Jan 25, 2010 at 6:12 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any idea how to workaround/solve this on windows host? I'm not sure I understand correctly. libtool prints a warning, but should not fail. Is the result usable? If not, then the build should end with an error in a later link: can you post it and its output? Thanks, Ralf Here it is: liba - should be static libb - should be dynamic, liking with liba without whole archive. Works on UNIX does not on Windows. Attached are the sources. Thanks, Alon. --- make all-am make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o b.lo b.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o /dev/null 21 mv -f .deps/b.Tpo .deps/b.Plo /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo './'`a.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT -DPIC -o .libs/liba_la-a.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o /dev/null 21 mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la liba.la ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la libb.la ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' Sorry to bother... but any news regarding this one?
Re: Disable --whole-archive when using convenience archives
On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any idea how to workaround/solve this on windows host? I'm not sure I understand correctly. libtool prints a warning, but should not fail. Is the result usable? If not, then the build should end with an error in a later link: can you post it and its output? Thanks, Ralf Here it is: liba - should be static libb - should be dynamic, liking with liba without whole archive. Works on UNIX does not on Windows. Attached are the sources. Thanks, Alon. --- make all-am make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o b.lo b.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o /dev/null 21 mv -f .deps/b.Tpo .deps/b.Plo /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo './'`a.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT -DPIC -o .libs/liba_la-a.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o /dev/null 21 mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la liba.la ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la libb.la ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' Sorry to bother... but any news regarding this one? Thanks! libtool-whole.tar.bz2 Description: BZip2 compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any idea how to workaround/solve this on windows host? I'm not sure I understand correctly. libtool prints a warning, but should not fail. Is the result usable? If not, then the build should end with an error in a later link: can you post it and its output? Thanks, Ralf Here it is: liba - should be static libb - should be dynamic, liking with liba without whole archive. Works on UNIX does not on Windows. Attached are the sources. Thanks, Alon. --- make all-am make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o b.lo b.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o /dev/null 21 mv -f .deps/b.Tpo .deps/b.Plo /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo './'`a.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT -DPIC -o .libs/liba_la-a.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o /dev/null 21 mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la liba.la ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la libb.la ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' libtool-whole.tar.bz2 Description: BZip2 compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
On Mon, Dec 21, 2009 at 6:21 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET: I have some convenience archives linked against several modules. I wish only required objects to be included in modules. Then make the convenience archives not be convenience archives any longer, i.e., make them libtool libraries. [...] In either case, they may end up being shared libraries (or both), so if you don't want that, add -static to libbar_la_LDFLAGS. I had to add -prefer-pic to CFLAGS in order it to work properly... :) Wow... this is an ugly workaround... Any reason why a simple switch to libtool --mode=link is not supported? Yes, I think this is by intention. What you do is, at least most of the time, ugly. Why do you need the library to be PIC? Usually, the reason for that is that lib1.la does end up included in a, or a couple of, shared libraries or modules somewhere. And at that point, you risk (exposing your users to) subtle bugs: if code from lib1 is present in several places, and contains static state (example: last random number of a RNG), then on some systems, different parts of the running executable might suddenly use different instances of that state. Eww. Typically, that's the point at which developers reconsider to make lib1 a proper shared library. Is it the first time someone needs this? No, but we've been able to convince most of the other guys that asked for this to reconsider. ;-) Hello Ralf, For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any ideas? Hello Ralf, Any idea how to workaround/solve this on windows host? Thanks! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
* Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any idea how to workaround/solve this on windows host? I'm not sure I understand correctly. libtool prints a warning, but should not fail. Is the result usable? If not, then the build should end with an error in a later link: can you post it and its output? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET: I have some convenience archives linked against several modules. I wish only required objects to be included in modules. Then make the convenience archives not be convenience archives any longer, i.e., make them libtool libraries. [...] In either case, they may end up being shared libraries (or both), so if you don't want that, add -static to libbar_la_LDFLAGS. I had to add -prefer-pic to CFLAGS in order it to work properly... :) Wow... this is an ugly workaround... Any reason why a simple switch to libtool --mode=link is not supported? Yes, I think this is by intention. What you do is, at least most of the time, ugly. Why do you need the library to be PIC? Usually, the reason for that is that lib1.la does end up included in a, or a couple of, shared libraries or modules somewhere. And at that point, you risk (exposing your users to) subtle bugs: if code from lib1 is present in several places, and contains static state (example: last random number of a RNG), then on some systems, different parts of the running executable might suddenly use different instances of that state. Eww. Typically, that's the point at which developers reconsider to make lib1 a proper shared library. Is it the first time someone needs this? No, but we've been able to convince most of the other guys that asked for this to reconsider. ;-) Hello Ralf, For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any ideas? ___ http://lists.gnu.org/mailman/listinfo/libtool
Disable --whole-archive when using convenience archives
Hello, Using: autoconf-2.63 automake-1.10.2 libtool-2.2.6a I have some convenience archives linked against several modules. I wish only required objects to be included in modules. But libtool's usage of --whole-archive forces the whole archive to be included in the module. I could not find any way to disable the --whole-archive injection. In the following example, both a.c and b.c are compiled and added to module.so, although only a.c is actually used. Removing the -Wl,--whole-archive from compilation solves this issue. The following is produced by libtool: bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -module -shared -no-undefined -o module.la -rpath /usr/local/lib m.lo lib1.la libtool: link: gcc -shared .libs/m.o -Wl,--whole-archive ./.libs/lib1.a -Wl,--no-whole-archive -Wl,-soname -Wl,module.so -o .libs/module.so Can anyone help? Thanks! Alon Bar-Lev. --- AUTOMAKE_OPTIONS = foreign 1.10 ACLOCAL_AMFLAGS = -I m4 noinst_LTLIBRARIES = lib1.la lib_LTLIBRARIES = module.la lib1_la_SOURCES = a.c b.c module_la_SOURCES = m.c module_la_LIBADD = lib1.la module_la_LDFLAGS = -avoid-version -module -shared -no-undefined ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Hello Alon,
* Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET:
I have some convenience archives linked against several modules.
I wish only required objects to be included in modules.
Then make the convenience archives not be convenience archives any
longer, i.e., make them libtool libraries.
You can make them normal libtool libraries with either
foo_LTLIBRARIES = libbar.la
but then they will be installed in $(foodir) ('foo' often being 'lib').
If you don't want that, then you can get automake to not install them,
but libtool still treat them as normal libraries with
noinst_LTLIBRARIES = libbar.la
libbar_la_LDFLAGS = -rpath /some/dir
In either case, they may end up being shared libraries (or both), so if
you don't want that, add -static to libbar_la_LDFLAGS.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Thank you for quick response (as usual... :) )
I had to add -prefer-pic to CFLAGS in order it to work properly... :)
Wow... this is an ugly workaround... Any reason why a simple switch to
libtool --mode=link is not supported? Is it the first time someone
needs this?
Thanks,
Alon.
---
AUTOMAKE_OPTIONS = foreign 1.10
ACLOCAL_AMFLAGS = -I m4
noinst_LTLIBRARIES = lib1.la
lib_LTLIBRARIES = module.la
lib1_la_CFLAGS = $(AM_CFLAGS) -prefer-pic
lib1_la_SOURCES = a.c b.c
lib1_la_LDFLAGS = -rpath $(libdir) -static
module_la_SOURCES = m.c
module_la_LIBADD = lib1.la
module_la_LDFLAGS = -avoid-version -module -shared -no-undefined
On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Hello Alon,
* Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET:
I have some convenience archives linked against several modules.
I wish only required objects to be included in modules.
Then make the convenience archives not be convenience archives any
longer, i.e., make them libtool libraries.
You can make them normal libtool libraries with either
foo_LTLIBRARIES = libbar.la
but then they will be installed in $(foodir) ('foo' often being 'lib').
If you don't want that, then you can get automake to not install them,
but libtool still treat them as normal libraries with
noinst_LTLIBRARIES = libbar.la
libbar_la_LDFLAGS = -rpath /some/dir
In either case, they may end up being shared libraries (or both), so if
you don't want that, add -static to libbar_la_LDFLAGS.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Hello Alon, please don't top-post, thanks. * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET: I have some convenience archives linked against several modules. I wish only required objects to be included in modules. Then make the convenience archives not be convenience archives any longer, i.e., make them libtool libraries. [...] In either case, they may end up being shared libraries (or both), so if you don't want that, add -static to libbar_la_LDFLAGS. I had to add -prefer-pic to CFLAGS in order it to work properly... :) Wow... this is an ugly workaround... Any reason why a simple switch to libtool --mode=link is not supported? Yes, I think this is by intention. What you do is, at least most of the time, ugly. Why do you need the library to be PIC? Usually, the reason for that is that lib1.la does end up included in a, or a couple of, shared libraries or modules somewhere. And at that point, you risk (exposing your users to) subtle bugs: if code from lib1 is present in several places, and contains static state (example: last random number of a RNG), then on some systems, different parts of the running executable might suddenly use different instances of that state. Eww. Typically, that's the point at which developers reconsider to make lib1 a proper shared library. Is it the first time someone needs this? No, but we've been able to convince most of the other guys that asked for this to reconsider. ;-) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Hello, On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: I had to add -prefer-pic to CFLAGS in order it to work properly... :) Wow... this is an ugly workaround... Any reason why a simple switch to libtool --mode=link is not supported? Yes, I think this is by intention. What you do is, at least most of the time, ugly. Oh... It depends of how you perceive ugly... :) Well... I have a plugin which shares code with programs. The plugin should be self-contained. And I have .a libraries which are common to both. In order to support this I must use this workaround for all libraries which are common to the plugin and the module. I just finished migrating a proprietary build system into autoconf/automake/libtool and this simple task became the most complex one. Why do you need the library to be PIC? Usually, the reason for that is that lib1.la does end up included in a, or a couple of, shared libraries or modules somewhere. True. I need to be linked into .so which is a standalone plugin. And at that point, you risk (exposing your users to) subtle bugs: if code from lib1 is present in several places, and contains static state (example: last random number of a RNG), then on some systems, different parts of the running executable might suddenly use different instances of that state. Eww. Well... I can think of a lot of bug that may result from incorrect use of tools... Typically, that's the point at which developers reconsider to make lib1 a proper shared library. Yes, but I cannot have dependencies for my plugin .so implementation. Is it the first time someone needs this? No, but we've been able to convince most of the other guys that asked for this to reconsider. ;-) I see... :) Thank you for your help... As long as there is a workaround I am happy... But... I think this requirement is not so extra ordinary. Thank you, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
