Re: shared library depending on static library on Solaris
Ralf Wildenhues dixit: Most arches do not support having non-pic code in a shared lib, for others pic is the default. Afaik, on linux, i386 is the only arch that actually supports non-pic code in a shared lib. Solaris on some arches, too, I believe. Having non-pic code in a shared lib has as effect that the lib actually isn't shared by several processes, so it's a waste of memory. ACK. It depends. I did not push myself to a reproducible test case, but I have heard and experienced at least one that not using -fpic/-fPIC and then making a shared library can cause misbe- haviour, even crash the app, under BSD. Some arches are more, some less forgiving (on ppc, PIC is default, but I'm on i386 and had the problem). //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
On Fri, Jun 10, 2005 at 06:37:15PM +0200, Ralf Wildenhues wrote: You could write a simple test that exposes this error. This would be extremely helpful, as we fail this issue on other systems as well (linux/x86_64 for example). The test could go somewhere like this: compile a lib statically, install it (the test suite has some default dirs for temporary installs), then build a shared lib that tries to link against it. Then build an executable that need symbols from both that shared and that static lib. Patches are always welcome. :) Patch against recent cvs version below. It successfully fails on Solaris. The actual test is generated from a test.in because I needed the path to INSTALL. A make dist will currently include both test.in and test because of some default rules. skimo -- Add test of a dynamic library depending on a static library. --- commit b9ffa64e2c09be1dbcf08ee1c96ebd13c5206ba8 tree c93508d37c9ab5ffc9a5876aeb0e8a728fe654d7 parent 95c814e157c44ea65170239702eb421fa833c2fd author Sven Verdoolaege [EMAIL PROTECTED] Wed, 22 Jun 2005 16:09:41 +0200 committer Sven Verdoolaege [EMAIL PROTECTED] Wed, 22 Jun 2005 16:09:41 +0200 Makefile.am |9 - configure.ac |1 + tests/sddemo.test.in | 50 + tests/sddemo/l1.c | 36 +++ tests/sddemo/l1.h | 31 ++ tests/sddemo/l2.c | 39 ++ tests/sddemo/l2.h | 31 ++ tests/sddemo/main.c | 35 ++ tests/sddemo/sysdep.h | 47 ++ 9 files changed, 278 insertions(+), 1 deletions(-) diff --git a/Makefile.am b/Makefile.am --- a/Makefile.am +++ b/Makefile.am @@ -381,6 +381,7 @@ COMMON_TESTS = \ tests/link.test tests/link-2.test tests/nomode.test \ tests/objectlist.test tests/quote.test tests/sh.test \ tests/suffix.test tests/tagtrace.test \ + tests/sddemo.test \ tests/cdemo-static.test tests/cdemo-make.test tests/cdemo-exec.test \ tests/demo-static.test tests/demo-make.test tests/demo-exec.test \ tests/demo-inst.test tests/demo-unst.test \ @@ -435,7 +436,13 @@ endif tests/demo-conf.test: libtool EXTRA_DIST += tests/defs.in tests/defs.m4sh \ - $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS) + $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS) \ + tests/sddemo/l1.c \ + tests/sddemo/l1.h \ + tests/sddemo/l2.c \ + tests/sddemo/l2.h \ + tests/sddemo/main.c \ + tests/sddemo/sysdep.h DIST_SUBDIRS += $(CONF_SUBDIRS) # The defs script shouldn't be recreated whenever the Makefile is diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -183,4 +183,5 @@ AM_CONDITIONAL(HAVE_RC, [test -n [$]_LT ## Outputs. ## ## ## AC_CONFIG_FILES([Makefile libltdl/Makefile]) +AC_CONFIG_FILES([tests/sddemo.test], [chmod +x tests/sddemo.test]) AC_OUTPUT diff --git a/tests/sddemo.test.in b/tests/sddemo.test.in new file mode 100644 --- /dev/null +++ b/tests/sddemo.test.in @@ -0,0 +1,50 @@ +#! /bin/sh +# sddemo.test.in - build a dynamic lib that depends on a static lib + +# Copyright (C) 2003, 2004 Free Software Foundation, Inc. +# This is free software; see the source for copying conditions. There is NO +# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, a copy can be downloaded from +# http://www.gnu.org/copyleft/gpl.html, or by writing to the Free +# Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. + +INSTALL=@INSTALL@ + +. tests/defs || exit 1 + +LIBTOOL=../../libtool +func_mkprefixdir +func_cd tests/sddemo +$LIBTOOL --mode=compile $CC -I. -static $CFLAGS -c l1.c -o l1.lo || \ + exit $EXIT_FAILURE +$LIBTOOL --mode=link $CC -static -rpath $prefix -o libl1.la l1.lo || \ + exit $EXIT_FAILURE +$LIBTOOL --mode=install $INSTALL libl1.la $prefix/libl1.la || \ + exit $EXIT_FAILURE +$LIBTOOL --mode=clean $RM libl1.la l1.lo + +$LIBTOOL --mode=compile $CC -I. $CFLAGS -c l2.c -o l2.lo || exit $EXIT_FAILURE +$LIBTOOL --mode=link $CC -shared -L$prefix -rpath $prefix -o libl2.la l2.lo
Re: shared library depending on static library on Solaris
On Sat, 11 Jun 2005, Kurt Roeckx wrote: This test is skipped on a few arches like x86-64, hppa and s390, and I think the test shouldn't exists at all. Most arches do not support having non-pic code in a shared lib, for others pic is the default. Afaik, on linux, i386 is the only arch that actually supports non-pic code in a shared lib. Having non-pic code in a shared lib has as effect that the lib actually isn't shared by several processes, so it's a waste of memory. Sun's Solaris supports it in some OS versions and under the right conditions. And yes, it is wasteful. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
On Fri, Jun 10, 2005 at 06:31:29PM +0200, Sven Verdoolaege wrote: I just tried this (this is not my development system; I just used the libtool created on another system before) and actually, it passes all tests (and skips one). deplibs_check_method may not be pass_all on your system. [...] SKIP: demo-nopic.test This test is skipped on a few arches like x86-64, hppa and s390, and I think the test shouldn't exists at all. Most arches do not support having non-pic code in a shared lib, for others pic is the default. Afaik, on linux, i386 is the only arch that actually supports non-pic code in a shared lib. Having non-pic code in a shared lib has as effect that the lib actually isn't shared by several processes, so it's a waste of memory. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
Hi Kurt, * Kurt Roeckx wrote on Sat, Jun 11, 2005 at 02:25:42PM CEST: On Fri, Jun 10, 2005 at 06:31:29PM +0200, Sven Verdoolaege wrote: I just tried this (this is not my development system; I just used the libtool created on another system before) and actually, it passes all tests (and skips one). deplibs_check_method may not be pass_all on your system. [...] SKIP: demo-nopic.test This test is skipped on a few arches like x86-64, hppa and s390, and I think the test shouldn't exists at all. (I suppose you also mean that libtool should not put nopic code into shared libs either; just removing the test doesn't change much.) Fair enough. I would actually agree with you on this issue, for the reasons you state. However, there is (was?) a significant user base (and possibly distributor people, I guess) with a strong opinion against this. Most notably some people/packages which depend on the resulting speed difference. I realize Libtool needs an overhaul in this area. My thoughts so far were either 1) disabling nopic in shared libs at all, or 2) on exactly those systems that allow it, enabling it, and also giving the user the possibility to change this behavior. (Which one to make the default?) But this is all wishful thinking for Libtool version in the future. Most arches do not support having non-pic code in a shared lib, for others pic is the default. Afaik, on linux, i386 is the only arch that actually supports non-pic code in a shared lib. Solaris on some arches, too, I believe. Having non-pic code in a shared lib has as effect that the lib actually isn't shared by several processes, so it's a waste of memory. ACK. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
Hi Sven, * Sven Verdoolaege wrote on Fri, Jun 10, 2005 at 06:31:29PM CEST: On Tue, Jun 07, 2005 at 09:34:41AM +0200, Ralf Wildenhues wrote: Is there a problem with my assumptions or with libtool ? This is a bug in libtool, I believe. deplibs_check_method may not be pass_all on your system. I just tried this (this is not my development system; I just used the libtool created on another system before) and actually, it passes all tests (and skips one). *snip* SKIP: demo-nopic.test demo-nopic is the one that will expose the limitation of the system: non-PIC objects may not be put in shared objects. We skip it correctly here, but we currently don't have a test that exposes the failure you reported, namely that we need to make sure that on these systems we do not try to link shared libs against static libs. billie$ uname -a SunOS billie 5.8 Generic_117350-24 sun4u sparc Unfortunately, I still don't know enough about Solaris to fix this right away without breaking other uses. Let me know if I can help in testing. You could write a simple test that exposes this error. This would be extremely helpful, as we fail this issue on other systems as well (linux/x86_64 for example). The test could go somewhere like this: compile a lib statically, install it (the test suite has some default dirs for temporary installs), then build a shared lib that tries to link against it. Then build an executable that need symbols from both that shared and that static lib. Patches are always welcome. :) Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
On Tue, Jun 07, 2005 at 09:34:41AM +0200, Ralf Wildenhues wrote: Hi Sven, I am very sorry it took me so long to look at this. Thanks for looking into this. Is there a problem with my assumptions or with libtool ? This is a bug in libtool, I believe. deplibs_check_method may not be pass_all on your system. I just tried this (this is not my development system; I just used the libtool created on another system before) and actually, it passes all tests (and skips one). .. PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-conf.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: dryrun.test PASS: demo-nofast.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: demo-pic.test PASS: demo-make.test PASS: demo-exec.test SKIP: demo-nopic.test PASS: demo-make.test PASS: demo-exec.test PASS: depdemo-nofast.test .. billie$ uname -a SunOS billie 5.8 Generic_117350-24 sun4u sparc Unfortunately, I still don't know enough about Solaris to fix this right away without breaking other uses. Let me know if I can help in testing. skimo ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
Hi Sven, I am very sorry it took me so long to look at this. * Sven Verdoolaege wrote on Tue, May 10, 2005 at 06:16:52PM CEST: I wrote a library called barvinok (http://www.kotnet.org/~skimo//barvinok/barvinok-0.15.tar.gz) which uses a static library called ntl. In configure.in, I simply do AC_CHECK_LIB(ntl, main,[],[ AC_MSG_ERROR(Need ntl) ]) so -lntl ends up in LIBS. Now, what I would assume that would happen is that libtool would notice that ntl is a static library and not link it into the shared barvinok library, but instead add -lntl to dependency_libs. Unfortunately, on Solaris, libtool does try to link in ntl in the shared library itself, resulting in relocation errors. /bin/sh ./libtool --mode=link g++ -g -O2 -L/home/sven/loop//lib -L/home/sven/loop//lib -o libbarvinok.la -rpath /home/sven/loop//lib -version-info 8:0:4 ev_operations.lo genfun.lo util.lo barvinok.lo -lntl -lpolylibgmp -lgmp *snip* Text relocation remains referenced against symbol offset in file unknown 0x148 /home/sven/loop//lib/libntl.a(tools.o) [..many more symbols..] This happens with both libtool 1.5.8 and 1.5.16. Acknowledged. Is there a problem with my assumptions or with libtool ? This is a bug in libtool, I believe. deplibs_check_method may not be pass_all on your system. billie$ uname -a SunOS billie 5.8 Generic_117350-24 sun4u sparc Unfortunately, I still don't know enough about Solaris to fix this right away without breaking other uses. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
shared library depending on static library on Solaris
I wrote a library called barvinok (http://www.kotnet.org/~skimo//barvinok/barvinok-0.15.tar.gz) which uses a static library called ntl. In configure.in, I simply do AC_CHECK_LIB(ntl, main,[],[ AC_MSG_ERROR(Need ntl) ]) so -lntl ends up in LIBS. Now, what I would assume that would happen is that libtool would notice that ntl is a static library and not link it into the shared barvinok library, but instead add -lntl to dependency_libs. Unfortunately, on Solaris, libtool does try to link in ntl in the shared library itself, resulting in relocation errors. /bin/sh ./libtool --mode=link g++ -g -O2 -L/home/sven/loop//lib -L/home/sven/loop//lib -o libbarvinok.la -rpath /home/sven/loop//lib -version-info 8:0:4 ev_operations.lo genfun.lo util.lo barvinok.lo -lntl -lpolylibgmp -lgmp g++ -shared -nostdlib /usr/local/gnu/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/gnu/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3/crtbegin.o .libs/ev_operations.o .libs/genfun.o .libs/util.o .libs/barvinok.o -Wl,-R -Wl,/home/sven/loop//lib -Wl,-R -Wl,/usr/local/lib/. -Wl,-R -Wl,/home/sven/loop//lib -Wl,-R -Wl,/usr/local/lib/. -L/home/sven/loop//lib -lntl /home/sven/loop//lib/libpolylibgmp.so /home/sven/loop//lib/libgmp.so -L/usr/local/gnu/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3 -L/usr/local/gnu/bin/../lib/gcc-lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3 -L/usr/local/gnu/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3/../../../../sparc-sun-solaris2.8/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3/../../../../sparc-sun-solaris2.8/lib -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/gnu/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3/../../.. -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3/../../.. /usr/local/lib/./libstdc++.so -L/usr2/SOURCES/S8/gcc-3.3/objdir/sparc-sun-solaris2.8/libstdc++-v3/src -L/usr2/SOURCES/S8/gcc-3.3/objdir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -L/usr2/SOURCES/S8/gcc-3.3/objdir/gcc -L/usr/local/sparc-sun-solaris2.8/bin -L/usr/local/sparc-sun-solaris2.8/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/../../../sparc-sun-solaris2.8/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/../.. -lm -lgcc_s /usr/local/gnu/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3/crtend.o /usr/local/gnu/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3/crtn.o -Wl,-h -Wl,libbarvinok.so.4 -o .libs/libbarvinok.so.4.4.0 Text relocation remains referenced against symbol offset in file unknown 0x148 /home/sven/loop//lib/libntl.a(tools.o) [..many more symbols..] This happens with both libtool 1.5.8 and 1.5.16. Is there a problem with my assumptions or with libtool ? What's the solution ? billie$ uname -a SunOS billie 5.8 Generic_117350-24 sun4u sparc billie$ gcc --version gcc (GCC) 3.3 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. billie$ ld -v GNU ld version 2.11.2 (with BFD 2.11.2) skimo ___ http://lists.gnu.org/mailman/listinfo/libtool
