Re: Configuring libtool HEAD branch.
Gary V Vaughan <[EMAIL PROTECTED]> writes: > Hi Dan, > Don't forget to at least Cc: one of the lists... I might be struck by > lightning before I get chance to reply ;-) Piggybacking off of Gary's response > On Monday 16 April 2001 11:05 pm, [EMAIL PROTECTED] wrote: >> - When building libtool without run-time-linking, my changes do still >> create a lib.a. However, it is an actual archive containing the >> shared object (just like the quirky way the rest of AIX does it). >> What you end up with is a libltdl.a that contains both the shared and the >> non-shared object. This is not really what was intended, and would >> likely cause problems if you ever really needed to use the non-shared >> object, but for the most part it seems to work. The only other thing I can >> think to do is not bulid the non-shared object in this case. But isn't this how AIX natively supports having both a shared and unshared version of the library available at the same time? I think this is actually closer to exactly what you want than one might think. I'm only remembering this very vaguely from discussion in other lists, but I seem to recall that AIX's native tools can then select static or shared linking by choosing which objects in the .a they pull in. Some vague memory also tells me that this is how shared library versioning is done (with differently named shared objects). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.4 test results for mips-sgi-irix6.5
gcc 2.95.3, SGI native ld. [...] FAIL: hardcode.test 411202:lt-hell: rld: Error: unresolvable symbol in lt-hell: foo 411202:lt-hell: rld: Error: unresolvable symbol in lt-hell: nothing 411202:lt-hell: rld: Fatal Error: this executable has unresolvable symbols PASS: build-relink.test [...] 412530:lt-depdemo: rld: Error: unresolvable symbol in /afs/ir/src/pubsw/development/libtool/build/@sys/depdemo/l4/.libs/libl4.so.1: var_l3 412530:lt-depdemo: rld: Error: unresolvable symbol in /afs/ir/src/pubsw/development/libtool/build/@sys/depdemo/l4/.libs/libl4.so.1: func_l3 412530:lt-depdemo: rld: Fatal Error: this executable has unresolvable symbols PASS: build-relink2.test [...] 1 of 83 tests failed Rerunning hardcode.test with VERBOSE=1: === Running hardcode.test = Running make hardcode in ../demo You may ignore any linking errors from the following command: gcc -g -O2 -o hc-direct main.o ./.libs/libhello.so -lm -Wl,-rpath -Wl,/afs/ir/src/pubsw/development/libtool/build/@sys/tests/_inst/lib || echo unsupported > hc-direct gcc -g -O2 -o hc-libflag main.o -Wl,-rpath -Wl,/afs/ir/src/pubsw/development/libtool/build/sgi_65/demo/.libs -L/afs/ir/src/pubsw/development/libtool/build/@sys/tests/_inst/lib -lhello -lm You may ignore any linking errors from the following command: LD_LIBRARYN32_PATH=./.libs gcc -g -O2 -o hc-libpath main.o -lhello -lm -Wl,-rpath -Wl,/afs/ir/src/pubsw/development/libtool/build/@sys/tests/_inst/lib || echo unsupported > hc-libpath ld32: FATAL 9 : I/O error (-lhello): No such file or directory collect2: ld returned 32 exit status gcc -g -O2 -o hc-minusL main.o -L./.libs -lhello -lm -Wl,-rpath -Wl,/afs/ir/src/pubsw/development/libtool/build/@sys/tests/_inst/lib || echo unsupported > hc-minusL = Finding libtool.m4's guesses at hardcoding values = Searching for hardcoded library directories in each program .libs was not hardcoded in `hc-direct', as libtool expected .libs was hardcoded in `hc-libflag', as libtool expected `hc-libpath' was not linked properly, as libtool expected .libs was hardcoded in `hc-minusL', which fooled libtool -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.4 test results for mips-sgi-irix6.5
Whoops, sorry, I should add that this was with: Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) Russ Allbery <[EMAIL PROTECTED]> writes: > gcc 2.95.3, SGI native ld. > [...] > FAIL: hardcode.test > 411202:lt-hell: rld: Error: unresolvable symbol in lt-hell: foo > 411202:lt-hell: rld: Error: unresolvable symbol in lt-hell: nothing > 411202:lt-hell: rld: Fatal Error: this executable has unresolvable symbols > PASS: build-relink.test > [...] > 412530:lt-depdemo: rld: Error: unresolvable symbol in >/afs/ir/src/pubsw/development/libtool/build/@sys/depdemo/l4/.libs/libl4.so.1: var_l3 > 412530:lt-depdemo: rld: Error: unresolvable symbol in >/afs/ir/src/pubsw/development/libtool/build/@sys/depdemo/l4/.libs/libl4.so.1: func_l3 > 412530:lt-depdemo: rld: Fatal Error: this executable has unresolvable symbols > PASS: build-relink2.test > [...] > ==== > 1 of 83 tests failed > -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.910) test results for i686-pc-linux-gnu (PASS)
Not like this is a surprise or anything, but for completeness Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for ld used by GCC... /usr/pubsw/bin/ld checking if the linker (/usr/pubsw/bin/ld) is GNU ld... yes Using gcc 2.95.3 === All 83 tests passed === Test suite is currently running on HP-UX 11.00, AIX 4.2, AIX 4.3, Tru64 4.0F, Solaris 2.6, Solaris 7, and Solaris 8. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.910) test results for powerpc-ibm-aix4.3.2.0 (FAIL)
Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... powerpc-ibm-aix4.3.2.0 checking build system type... powerpc-ibm-aix4.3.2.0 checking for ld used by GCC... /bin/ld checking if the linker (/bin/ld) is GNU ld... no Using gcc 2.95.3 There was an error during configure: checking whether the linker (/bin/ld) supports shared libraries... ../../configure[3572]: shared: not found yes The test results weren't nearly as good: PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-static.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: cdemo-conf.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-conf.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test FAIL: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-conf.test FAIL: mdemo-make.test PASS: mdemo-unst.test FAIL: dryrun.test PASS: demo-pic.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-nopic.test PASS: demo-make.test FAIL: demo-exec.test PASS: cdemo-shared.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-shared.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-inst.test FAIL: hardcode.test FAIL: build-relink.test PASS: noinst-link.test PASS: demo-unst.test PASS: depdemo-shared.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test FAIL: build-relink2.test PASS: depdemo-unst.test PASS: mdemo-shared.test FAIL: mdemo-make.test PASS: mdemo-unst.test PASS: assign.test PASS: link.test PASS: link-2.test PASS: nomode.test PASS: quote.test PASS: sh.test PASS: suffix.test = 15 of 69 tests failed = I don't have the time to do specific debugging, but if you want any of these tests rerun specifically, I can do that and send the output. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.910) test results for sparc-sun-solaris2.8 (FAIL)
I assume that these are mostly the known Solaris failures. Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... sparc-sun-solaris2.8 checking build system type... sparc-sun-solaris2.8 checking for ld used by GCC... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no Using gcc 2.95.3. = 12 of 83 tests failed = Failing tests: FAIL: demo-unst.test FAIL: depdemo-unst.test FAIL: mdemo-unst.test FAIL: demo-unst.test FAIL: depdemo-unst.test FAIL: mdemo-unst.test FAIL: dryrun.test FAIL: demo-unst.test FAIL: depdemo-unst.test FAIL: demo-unst.test FAIL: depdemo-unst.test FAIL: mdemo-unst.test -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.910) test results for sparc-sun-solaris2.[67] (FAIL)
Identical results to sparc-sun-solaris2.8, with the same failing tests. Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... sparc-sun-solaris2.6 checking build system type... sparc-sun-solaris2.6 checking for ld used by GCC... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no and checking host system type... sparc-sun-solaris2.7 checking build system type... sparc-sun-solaris2.7 checking for ld used by GCC... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no gcc 2.95.3 in use on both. On both systems: = 12 of 83 tests failed = with the same list of failing tests as Solaris 8. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.910) test results for rs6000-ibm-aix4.2.1.0 (FAIL)
Similar results to AIX 4.3, including the same error during configure. Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... rs6000-ibm-aix4.2.1.0 checking build system type... rs6000-ibm-aix4.2.1.0 checking for ld used by GCC... /usr/pubsw/lib/gcc-lib/rs6000-ibm-aix4.2.1.0/2.8.1/ld checking if the linker (/usr/pubsw/lib/gcc-lib/rs6000-ibm-aix4.2.1.0/2.8.1/ld) is GNU ld... no Using gcc 2.8.1 with a symlink to the AIX ld in the gcc library directory, which is why the weird output above. This error message showed up during configure: checking whether the linker (/usr/pubsw/lib/gcc-lib/rs6000-ibm-aix4.2.1.0/2.8.1/ld) supports shared libraries... ../../configure[3572]: shared: not found yes and the test results were: 9 of 55 tests failed FAIL: demo-make.test FAIL: depdemo-make.test FAIL: mdemo-make.test FAIL: dryrun.test FAIL: demo-make.test FAIL: demo-make.test FAIL: demo-make.test FAIL: depdemo-make.test FAIL: mdemo-make.test When I run demo-make.test by hand, though, it seems to work (?): === Running demo-make.test Making in ../demo /bin/sh ./libtool --mode=link gcc -O2 -o hell main.o libhello.la libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `hell' will be relinked during installation gcc -O2 -o .libs/hell main.o -L./.libs -lhello -lm -Wl,-bnolibpath -Wl,-blibpath:/afs/ir/src/pubsw/development/libtool/build/rs_aix42/demo/.libs:/usr/lib:/lib -Wl,-bnolibpath -Wl,-blibpath:/afs/ir/src/pubsw/development/libtool/build/@sys/tests/_inst/lib:/usr/lib:/lib creating hell /bin/sh ./libtool --mode=link gcc -O2 -o hell.static main.o libhello.la libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `hell.static' will be relinked during installation gcc -O2 -o .libs/hell.static main.o -L./.libs -lhello -lm -Wl,-bnolibpath -Wl,-blibpath:/afs/ir/src/pubsw/development/libtool/build/rs_aix42/demo/.libs:/usr/lib:/lib -Wl,-bnolibpath -Wl,-blibpath:/afs/ir/src/pubsw/development/libtool/build/@sys/tests/_inst/lib:/usr/lib:/lib creating hell.static gcc -DPACKAGE=\"hell\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_STRING_H=1 -DHAVE_MATH_H=1 -I. -I/afs/ir/src/pubsw/development/libtool/tests/../demo -O2 -c /afs/ir/src/pubsw/development/libtool/tests/../demo/dlmain.c /bin/sh ./libtool --mode=link gcc -O2 -o helldl -export-dynamic -dlpreopen libhello.la dlmain.o rm -f .libs/helldl.nm .libs/helldl.nmS .libs/helldl.nmT creating .libs/helldlS.c extracting global C symbols from `./.libs/libhello.so.2' (cd .libs && gcc -c -fno-builtin -fno-rtti -fno-exceptions "helldlS.c") rm -f .libs/helldlS.c .libs/helldl.nm .libs/helldl.nmS .libs/helldl.nmT libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `helldl' will be relinked during installation gcc -O2 -o .libs/helldl .libs/helldlS.o dlmain.o -L./.libs -lhello -lm -Wl,-bnolibpath -Wl,-blibpath:/afs/ir/src/pubsw/development/libtool/build/rs_aix42/demo/.libs:/usr/lib:/lib -Wl,-bnolibpath -Wl,-blibpath:/afs/ir/src/pubsw/development/libtool/build/@sys/tests/_inst/lib:/usr/lib:/lib creating helldl -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.910) test results for alpha-dec-osf4.0f (PASS)
There were some warnings during some of the tests, though. Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... alpha-dec-osf4.0f checking build system type... alpha-dec-osf4.0f Using vendor ld and gcc 2.95.3. 21897:.libs/lt-hell: /sbin/loader: Error: Unresolved symbol in .libs/lt-hell: nothing 21897:.libs/lt-hell: /sbin/loader: Error: Unresolved symbol in .libs/lt-hell: foo 21897:.libs/lt-hell: /sbin/loader: Fatal Error: this executable has unresolvable symbols PASS: build-relink.test 15263:.libs/lt-depdemo: /sbin/loader: Error: Unresolved symbol in /afs/ir.stanford.edu/src/pubsw/development/libtool/build/alpha_dux40/depdemo/l4/.libs/libl4.so: var_l3 15263:.libs/lt-depdemo: /sbin/loader: Fatal Error: this executable has unresolvable symbols PASS: build-relink2.test === All 83 tests passed === -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.910) test results for hppa2.0n-hp-hpux11.00 (FAIL)
I was unable to even get the test suite to complete on this platform; every time the mdemo tests ran, the program it was running went runaway and had to be kill -9'd. I got tired of doing this by about the fifth time. :/ Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... hppa2.0n-hp-hpux11.00 checking build system type... hppa2.0n-hp-hpux11.00 Using vendor ld and gcc 2.95.3. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.910) test results for hppa2.0n-hp-hpux11.00 (FAIL)
libtool <[EMAIL PROTECTED]> writes:
> On Mon, Apr 23, 2001 at 09:10:20AM -0700, Russ Allbery wrote:
>> I was unable to even get the test suite to complete on this platform;
>> every time the mdemo tests ran, the program it was running went runaway
>> and had to be kill -9'd. I got tired of doing this by about the fifth
>> time. :/
> Compile the following program and run 'nm | grep dlopen' against it
> and mail the results to the list:
> char dlopen();
> int main() {
> dlopen();
> }
I'll do this if the new patch doesn't fix the problem.
>> Using vendor ld and gcc 2.95.3.
> FYI, GCC 2.95.x does *not* "officially" support HP-UX 11.00.
I know. It still works for most cases.
I'm now checking with the vendor compiler and the new patch and will let
you know the results.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.913) test results for sparc-sun-solaris2.[678] (PASS)
Yup, that fixed it. Configuring libtool 1.3e (1.913 2001/04/23 21:59:34) sparc-sun-solaris2.6 sparc-sun-solaris2.7 sparc-sun-solaris2.8 all with gcc 2.95.3 and vendor ld. === All 83 tests passed === on all three of them. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.910) test results for hppa2.0n-hp-hpux11.00 (FAIL)
libtool <[EMAIL PROTECTED]> writes:
> On Mon, Apr 23, 2001 at 09:10:20AM -0700, Russ Allbery wrote:
>> I was unable to even get the test suite to complete on this platform;
>> every time the mdemo tests ran, the program it was running went runaway
>> and had to be kill -9'd. I got tired of doing this by about the fifth
>> time. :/
> Compile the following program and run 'nm | grep dlopen' against it
> and mail the results to the list:
> char dlopen();
> int main() {
> dlopen();
> }
% cat test.c
char dlopen();
int main() {
dlopen();
}
% cc -o test test.c
/usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (test.o) was detected. The
linked output may not run on a PA 1.x system.
% nm test | grep dlopen
dlopen | |undef |code |
dlopen | 9208|uext |stub |
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
1.3e (1.913) test results for hppa2.0n-hp-hpux11.00 (FAIL)
That patch fixed the hang. The test results still aren't pretty. Configuring libtool 1.3e (1.913 2001/04/23 21:59:34) checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking host system type... hppa2.0n-hp-hpux11.00 checking build system type... hppa2.0n-hp-hpux11.00 checking for non-GNU ld... /bin/ld checking if the linker (/bin/ld) is GNU ld... no (vendor compiler and linker) FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-inst.test FAIL: mdemo-make.test FAIL: mdemo-exec.test FAIL: mdemo-inst.test FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-inst.test FAIL: mdemo-make.test FAIL: dryrun.test FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-inst.test FAIL: mdemo-make.test = 19 of 66 tests failed = -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.913) test results for hppa2.0n-hp-hpux11.00 (FAIL)
libtool <[EMAIL PROTECTED]> writes: > On Tue, Apr 24, 2001 at 12:46:33AM -0700, Russ Allbery wrote: >> That patch fixed the hang. The test results still aren't pretty. > Apply the fix I posted to libtool-patches. That should bring it down to > 6 failures. I assume that this is the one now in the current CVS source, and that does indeed get it down to six failures. Test results coming in a separate message. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.4a (1.923) test results for hppa2.0n-hp-hpux11.00 (FAIL)
Configuring libtool 1.4a (1.923 2001/04/25 01:01:22) checking for gcc... (cached) cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking host system type... hppa2.0n-hp-hpux11.00 checking build system type... hppa2.0n-hp-hpux11.00 checking for non-GNU ld... (cached) /bin/ld checking if the linker (/bin/ld) is GNU ld... (cached) no FAIL: cdemo-make.test FAIL: demo-make.test FAIL: depdemo-make.test FAIL: mdemo-make.test FAIL: mdemo-exec.test FAIL: mdemo-inst.test 6 of 66 tests failed -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
Rob Browning <[EMAIL PROTECTED]> writes: > The problem I'm talking about is if Makefile.am's use > LDFLAGS = `gnome-config --libs foo` `foo-config --libs bar` > then if you've got a normal gnome-dev package installed, such that > it's libs are in /usr/lib, it will (or at least it used to) put > -L/usr/lib into LDFLAGS ahead of whatever foo-config specifies. This is a bug in the packaging that should be reported to your distribution. Under no circumstances should /usr/lib, /usr/include, and other such default paths be included in the configured link or compile flags, and the packager needs to fix them if they are. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > How is the application developer to know which directories are searched > by default? One can safely assume that /usr/lib and /usr/include are always searched by default. Those are the only ones that I'd expect people to automatically leave out of the package configuration scripts. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
Lars J Aas <[EMAIL PROTECTED]> writes: > There are always exceptions. A bunch of projects I am a developer on > uses the MS Visual C++ compiler when building on Cygwin platforms. > Would you be surprised to know that VC++ does *not* search Cygwins > /usr/include for headers by default? :) This sort of thing is why autoconf and friends support setting CPPFLAGS and LDFLAGS in the environment. :) I think it's unreleastic to try to take into account every bizarre combination of compilers and run-time; including -I/usr/include can completely break things and including -L/usr/lib makes it almost impossible to use locally-installed versions of vendor libraries, so they both cause significant enough problems that I think it's worth asking the people with odd compilers to set the appropriate environment variables themselves if the compiler they're using really needs to be told about those directories. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Werner Koch writes: > (4) Let libtool do something. This may be an option to detect > -Wl,--version-script=foo on the command line and hook in a sed to > transform the symbols. It is pretty common that symols are all prefixed > with something like "foo_" or "_foo_" and thus the option could take a > list of these prefixes and - if a symbol prefix is required - transform > the version script. I would dearly, dearly love for libtool to pick up a --version-script option that would pass in the full version script on platforms with linkers that understand it, turn it into a symbol export list on platforms that only support that, and suppress it entirely if the linker doesn't have any relevant capabilities. That would save me a ton of maintenance burden on some of my packages, and it would then be easy to add a feature like the above as well. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Ralf Wildenhues writes:
> * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST:
>> I would dearly, dearly love for libtool to pick up a --version-script
>> option that would pass in the full version script on platforms with
>> linkers that understand it, turn it into a symbol export list on
>> platforms that only support that,
> is this doable programmatically? Without a full version script parser?
You would need a parser, but I don't think the parser needs to be
particularly complicated.
>> and suppress it entirely if the linker doesn't have any relevant
>> capabilities. That would save me a ton of maintenance burden on some
>> of my packages, and it would then be easy to add a feature like the
>> above as well.
> Can somebody try to come up with a more detailed set of semantics, so we
> can judge a bit better whether this is feasible? If it is, any
> volunteers on implementing this?
I can take a pass at starting. All that I need for my packages is to
support the basic version syntax:
{
global:
;
;
local:
*;
};
On platforms with linkers that support regular ELF versioning, libtool
would need to figure out the right flag to pass to the linker and then add
it to the link line. On platforms that don't support that sort of version
script, libtool should extract the symbols listed in the global section
and then treat this flag as equivalent to -export-symbols pointing to a
file containing just the list of symbols in the global section.
Obviously, there are a bunch of other things you can do with symbol
versioning and this wouldn't be a replacement for what, say, glibc does.
But I bet it would be a good 80% solution.
> Do you know the gnulib module lib-symbol-versions? (No, it's not a
> complete solution.)
I hadn't looked at it before. It looks like all that does is check
whether --version-script is supported by the linker. I suspect that will
only cover GNU ld and Solaris ld on ELF. The fallback to -export-symbols
is the main feature that I'd really like to see, since that's supported on
more platforms and satisfies another major reason why people use version
scripts.
I suppose one could use lib-symbol-versions in conjunction with a
separately-maintained or generated export symbols map and apply both of
them. I haven't tried that to see if there are any bad interactions
between -export-symbols and versioned symbols.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Mike Frysinger writes: > alternative might be to do something like -export-symbols where libtool > has its own method for managing lists of symbols, but extend it to > handle versioning information as available with GNU/Solaris linkers. > then that would take care of outputting the version script with the > symbol prefix which libtool already knows. That might be a cleaner way of implementing the 80% solution. For most packages, I suspect that all you need to do is add the default symbol version string to the existing -export-symbols list as input parameters and then have libtool generate a symbol versioning file giving all symbols that version and listing everything in -export-symbols as global, with a local: *; section. There are nice things that you can do with a more sophisticated approach to versioning the symbols, but most use of symbol versioning is to avoid conflicts when multiple versions of a shared library are loaded at the same time, not to do more sophisticated things like provide multiple versions of a function bound to different symbol versions. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bug#9257: configure errors after upgrade to libtool 2.4
Julien ÉLIE writes: > It seems to be related to: > SED='`$ECHO "$SED" | $SED "$delay_single_quote_subst"`' > Xsed='`$ECHO "$Xsed" | $SED "$delay_single_quote_subst"`' > macro_version='`$ECHO "$macro_version" | $SED "$delay_single_quote_subst"`' > macro_revision='`$ECHO "$macro_revision" | $SED "$delay_single_quote_subst"`' > [...] > Thanks beforehand for your help on that subject. INN is trying to do something weird by making use of libtool conditional (my fault originally), and I suspect that something about the structure of its configure.ac is causing $delay_single_quote_subst to not be set to anything, leading sed to be invoked with the empty string as a command. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Several questions about libtool
Bob Friesenhahn writes: > On Fri, 6 Jan 2012, Peter O'Gorman wrote: >> This is still an issue, libtool always adds all dependencies. Many >> packages assume this and don't explicitly add required dependencies to >> Makefile.am etc. I don't recall the arguments for not changing this >> when building shared. IIRC Scott tried to include Debian's patch at >> some point. I'll look it up in the archives later. > Some systems (e.g. GNU Linux) add library implicit dependencies at link > time while others (e.g. Solaris) only seem to add them at run-time and > will fail to link if the dependencies are not also listed. I don't believe this is correct. GNU/Linux does not add implicit dependencies at link time; it only links with the libraries that you explicitly list. ELF doesn't require that all symbols be resolved during the link, only the symbols in the thing that you're linking. This behavior is, so far as I know, the same on both GNU/Linux and on Solaris. On an ELF system, if linking fails, that means that what you're trying to link references symbols in a library that you're not including, not that one of the libraries that you link against has unreferenced symbols. ELF build-time linkers should not care about the latter; that's handled by the runtime loader. > Some systems require that no symbols remain unresolved in order to > produce a shared library. This refers only to the binary or shared library itself, not by symbols used by shared libraries that it depends on. > Libtool's mode of operation works with static builds and on systems > where all libraries have to be supplied at link time. Of which there are very few still in existence in terms of widespread use, since most systems now use ELF or (like Mac OS X) some other object format that doesn't require this. Solaris is definitely not one of them. I believe you may still need this on such platforms as AIX or HP-UX that use a much different object format, but I'm not at all certain of that; it's been years since I've used them. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Several questions about libtool
Russ Allbery writes: > I don't believe this is correct. GNU/Linux does not add implicit > dependencies at link time; it only links with the libraries that you > explicitly list. ELF doesn't require that all symbols be resolved during > the link, only the symbols in the thing that you're linking. And, I should add, it's not necessarily the case that even this is required, although that varies. The default on GNU/Linux is to not care about unresolved symbols in shared libraries (but to care about them in executables). So you can generate a shared library that can't be used without linking with other shared libraries. But this is certainly not good practice; the behavior is there to support dynamically loadable modules that should have unresolved symbols that are resolved by the binary that's loading them, such as Apache modules. Shared libraries should always be linked with all libraries that they use *directly* (and should never be linked with libraries that they use only indirectly) on ELF systems with proper run-time linker support for transitive NEEDED (which I believe is all of them in common use). -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Several questions about libtool
Peter Rosin writes: > Russ Allbery skrev 2012-01-07 03:13: >> Of which there are very few still in existence in terms of widespread >> use, since most systems now use ELF or (like Mac OS X) some other >> object format that doesn't require this. Solaris is definitely not one >> of them. I believe you may still need this on such platforms as AIX or >> HP-UX that use a much different object format, but I'm not at all >> certain of that; it's been years since I've used them. > You are somehow forgetting Windows, probably the most widespread system > of them all. On Windows, you have to specify all libraries at link time > and Libtool helps with that. Indeed, I did forget Windows. (Although while it's the most widespread system of them all, it's a small fraction of the platforms on which people use Libtool on a day-to-day basis.) I wouldn't argue for breaking Libtool's ability to handle such platforms, or for that matter old UNIX platforms that don't support transitive resolution of shared library dependencies. But I think Libtool needs some mechanism to correctly support platforms where adding spurious NEEDED ELF metadata is wrong and causes serious issues for distributions. The pkg-config approach seems to work reasonably well in practice. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Several questions about libtool
Bob Friesenhahn writes: > I think that it is wrong to solely blame libtool for this state of > affairs. In order for a project to work properly on non-ELF systems, or > where installed shared libraries have abbreviated/truncated ELF implicit > dependencies, or where static libraries are involved, the project needs > to add all dependencies to LIBS during the configure run. pkg-config is an excellent example of an alternative way of handling this that does not have this problem, and it includes Autoconf support. One interesting possible solution to this problem would be to eliminate Libtool *.la files in favor of pkg-config or something similar, rather than continuing to maintain two different mechanisms for doing largely the same thing. > I do agree that a tool can help solve these issues. The linker itself > is in the best position to know which library dependencies are really > needed and to skip those which are not. It turns out that this is harder than it looks. --as-needed causes obscure failures in places where the dependency really is needed although the linker can't figure that out. The pkg-config solution allows the maintainer of the library to declare the necessary behavior for both cases: working transitive dependency resolution, and situations where this cannot be relied upon. The build system then chooses based on the situation. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Several questions about libtool
Bob Friesenhahn writes: > On Sat, 7 Jan 2012, Russ Allbery wrote: >> pkg-config is an excellent example of an alternative way of handling >> this that does not have this problem, and it includes Autoconf support. > What do you mean by "it includes Autoconf support". Do you mean that it > provides an Autoconf macro which makes pkg-config easier to use? Yes. > Regardless, Autoconf's configure will still make subsequent decisions > based on trial and error (by running the compiler and linker). Do you mean for detecting other libraries? Only for libraries without pkg-config support. You of course can't solve the whole problem overnight, but there's quite a bit of movement towards pkg-config support already, including in a bunch of low-level libraries that lots of things use. Subsequent probes that need to link with the library can use the shell variables set by pkg-config. > They may seem like they do the same thing but perhaps they do 20-30% of > the same thing (e.g. dependency info). The .la files used in the build > tree are very much needed since it is unlikely that builds will work at > all without them (and libtool needs them). I didn't say that pkg-config and Libtool did the same thing. I said that pkg-config configuration files and Libtool *.la files do largely the same thing, namely store metadata about libraries. pkg-config configuration files are simple key-value structures, and the additional information that Libtool needs to do the correct thing inside the build tree would not be difficult to represent in that format so far as I can tell. In fact, I think pkg-config would benefit from tracking some of the additional information that Libtool *.la files track. Or one can of course just add the same separation of dependency information to the Libtool *.la file format. It just seems unnecessary to have two file formats for doing the same thing, and the pkg-config file format is somewhat nicer. But this is all implementation details; I don't really care which way the information is represented. > Pkg-config is optional software which only really works when it is > properly cared for and fed correctly. The same is true of Libtool. :) > The obvious "solution" is that there should be a mode in which libtool > does not apply any ".la" dependency libraries from an installed .la file > unless they are known to be static libraries, or static libraries are > otherwise involved. I don't think you can just drop all dependencies for shared libraries, because some shared libraries do want the client to link with a dependent library for various complicated reasons. GTK+ and GDK are the most frequently cited example. My impression is that you don't want to try to do this with magic, because the magic will occasionally be wrong. That's the advantage of the pkg-config method. It lets the library maintainer, who actually knows what's going on, specify the desired behavior. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Several questions about libtool
Bob Friesenhahn writes: > On Sat, 7 Jan 2012, Russ Allbery wrote: >> Do you mean for detecting other libraries? Only for libraries without >> pkg-config support. > For detecting library features such as the availabilty of functions. Yes, it deals with that fine. Not that that's really on-topic, since I'm not advocating everyone use pkg-config. > Except that libtool is already embedded (in one vintage or another) in > the source code of perhaps 5000 (???) different packages. This makes > the pace of change somewhat glacial. So? New versions are still being released, and people eventually upgrade. I didn't say that we could resolve this problem overnight. But I guarantee it won't ever get fixed if, every time it comes up, the response is negativity and defeatism about why it can't be fixed. It's frustrating that GNU/Linux distributions have to drop *.la files completely, dropping the other features that Libtool could be providing, because of this ongoing issue. Yes, it's not a trivial problem to solve and it requires some thought about how to specify new linking semantics in different situations, combined with detection of when one is in those situations, but it's not impossible. > Believe it or not, there are still people who download source packages > and install software by building it from source code, or who develop new > software from scratch, or by modifying existing source code. Due to > this, the pristine environment that the GNU/Linux distribution package > maintainer is aware of is not necessarily representative of the user's > system, or the user's intentions. Given the principles of free > software, we should not assume that software users will only get the > software via carefully-prepared and managed binary packages provided by > an OS distribution. I don't see what this have to do with the library maintainer knowing whether or not, for systems with ELF transitive dependency closure, clients of their libraries should be linked with other libraries or can be linked only with their library. This is not a system-specific property, nor is it something that is unknowable outside of a developer's environment. It does take some education of library maintainers on the issues, and there have, of course, been bugs in pkg-config files. But they get dealt with. It's really not that horribly hard of a problem for most libraries. For nearly all libraries, in the pkg-config world, you can just put the library itself in Libs and the libraries it links with in Libs.private. There are some situations where you have to do something more complex, but those are normally libraries that are more complex and have more expert maintainers. > Autotools needs to satisfy the requirements of completely different > types of users. This means that it still needs to work (best-effort) if > pkg-config offers up some wrong (perhaps stale) information, or if the > user has several independent (or complimentary) pkg-config installations > on his system. It also needs to work if pkg-config is not available at > all. Of course. I think you've lost track of what I'm talking about. I'm pointing to pkg-config as a system that people have used to solve this problem as something from which Libtool could pull ideas for how to fix this problem in Libtool. It doesn't make any sense to worry about pkg-config files being stale or out of date in that context; the point is that this would be incorporated into Libtool as a feature. In doing so, I think there's some appeal in looking at the pkg-config file format and seeing if the *.la file format could be merged with it, but that was just an aside and is not something I feel strongly about. > I feel that I may have gotten a bit off track here, but it should be > clear that libtool needs to err towards the most reliable mechanisms by > default (the software should build and work by default if at all > possible) but also provide the features that distribution maintainers > need. Of course. I've never advocated anything different. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Libtool mishandling of C++ libraries requiring -pthread
Hello folks, I just ran into Debian bug #468555: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468555 which appears to not be something that was introduced in Debian, but is still a problem in the general Libtool 2.4.2 release. There is discussion in that bug log (the libgcc part no longer seems to be an issue), but the basic summary is that Libtool uses -nostdlib when linking C++ libraries, and -nostdlib suppresses the action of -pthread at the link phase and therefore g++ doesn't add -lpthread to the final link. The result is a shared library with unresolved pthread symbols. I think the primary question is why Libtool is using -nostdlib when linking C++ libraries. The bug discussion at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 says that it's because of some other issue with libstdc++ linkage with dlopened modules depending on C++ libraries, but this dates from 2005, and breaking C++ libraries that need threading seems like a bad outcome. Does this problem still exist? Can this workaround just be dropped? Note that the GCC maintainters closed the bug requesting -pthread still add -lpthread even under -nostdlib as invalid. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: foo-config scripts and removed .la files
Werner LEMBERG writes: > My question is how to handle this properly. Shall the logic to test for > the existence of the .la in the foo-config file or in the configuration > script which actually uses foo-config? And what exactly should be done > if no .la file is available? I suppose it's best to fall back to the > standard foo-config option `--libs'. If there is no *.la file available, that almost certainly means that you're on a platform where transitive shared library dependencies work properly (since that's the motivating reason for dropping the *.la files). I would therefore check in your configure script whether the *.la file you got from the --libtool option exists, and, if not, simply link directly with only the library you're using (-lfreetype, for instance) and assume everything will work. That of course doesn't work if you want to do static linking, but platforms dropping the *.la files are normally making a conscious decision to not support static linking anyway. I would also encourage any library maintainer who is providing a *-config script to also provide a pkgconfig file, since pkgconfig addresses the issue that is causing distributions to drop the *.la files and they're becoming more and more widespread beyond their initial community and are well-supported in Autoconf. Although that doesn't address your immediate issue. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: lazy symbol binding failed - on MacOSX 10.7 and 10.8
Satz Klauer writes: > This line looks a bit strange to me: > libtool: link: g++ -g -O2 -Wl,-whole-archive -Wl,-no-whole-archive -o > .libs/baz baz.o -Wl,-bind_at_load ../foo/libfoo.a > ../bar/.libs/libbar.dylib > g++ looks like some GCC-type compiler, so GNU-specifics should not be > a problem!? -Wl says to pass the flag verbatim to the linker. It's common to use the system linker even with non-system compilers. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: make dist for both Debian and Fedora?
Daniel Pocock writes: > I use a Debian system to run autoreconf and bootstrap/make dist releases > for various projects (e.g. reSIProcate) > When using the release tarball on a system like Fedora, issues with > hard-coded rpath have been discovered. > Apparently I am not alone, and this discussion has come up before in RPM > packaging. On the RPM packaging request for reSIProcate, I've gathered > links to a few different discussions about the issue: > https://bugzilla.redhat.com/show_bug.cgi?id=892625#c11 This appears to actually be a Libtool issue, not Automake. Cc'ing the relevant mailing list. The key message appears to be: http://lists.fedoraproject.org/pipermail/packaging/2010-June/007187.html which says that Fedora patches Libtool to recognize /usr/lib64 as a system library path so that Libtool won't generate rpath references to it. If that's still the case, it seems like that's something that Libtool should add in the upstream source. It seems unlikely to me that a system would have a /usr/lib64 directory that isn't part of the standard search path; either that path pattern won't be used at all (as with Debian/Ubuntu multiarch) or it will be the 64-bit multiarch system library path. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: why is ldconfig needed after installation
Peter Johansson writes: > I just installed a library with libtool (via automake generated rules) > and when trying to use the lib I get this: > error while loading shared libraries: libyat.so.9 > which is going away if I issue > sudo ldconfig /us/local/lib > My question is why is that even needed, as I thought libtool already did > that. No? ldconfig has to be run because the dynamic linker maintains a cache of available libraries that has to be updated. libtool does this when run with libtool --mode=finish on the installation directory. I'm not sure if it does this when it thinks the directory isn't listed in the system library search path, though. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: modules have a soname?
Simon Josefsson writes: > I'm tracking down why I get warnings from dpkg-shlibdeps on a package > that builds dlopen modules with libtool. For reference, a build log is > available here: > https://buildd.debian.org/status/fetch.php?pkg=jabberd2&arch=amd64&ver=2.3.4-1%2Bb1&stamp=1446749350 > According to dpkg-shlibdeps dlopen modules should not have a soname: >"A private library (like a plugin) should not have a SONAME and >doesn't need to be versioned." > See http://linux.die.net/man/1/dpkg-shlibdeps for more text. > However when I build the package manually I can see that libtool does > add a soname to the module: libtool adds an SONAME unless -avoid-version is passed in the libtool arguments. Unless there's some use for the SONAME, it's generally best practice to use -avoid-version when creating plugins. In other words, this is probably an upstream Makefile issue rather than a problem with either libtool or dpkg-shlibdeps. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: modules have a soname?
Simon Josefsson writes: > Is this intentional, or should we start to track down how -Wl,-soname > was added and treat that as a bug? The manual says: > '-avoid-version' > Tries to avoid versioning (*note Versioning::) for libraries and > modules, i.e. no version information is stored and no symbolic > links are created. If the platform requires versioning, this > option has no effect. > I don't know whether libtool regards the debian/gnu/linux/elf platform > as requiring versioning or not. Debian GNU/Linux definitely does not require versioning. I think I was wrong in my original message and Libtool does always add the SONAME, just not with a version. I just checked one of my packages in Debian (webauth, specifically libapache2-mod-webauth), and the modules that it builds do actually have an SONAME. However, dpkg-shlibdeps doesn't care. So maybe this is a problem in that tool where it should be suppressing that error for your package as well? You can see the build logs at: https://buildd.debian.org/status/fetch.php?pkg=webauth&arch=amd64&ver=4.7.0-3%2Bb1&stamp=1446816432 -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: binutils 2.28 breaking libtool for test programs when -no-install is used
Thomas Jahns writes: > On 06/01/2017 11:09 AM, Vincent Lefevre wrote: >> On 2017-06-01 09:56:29 +0200, Thomas Jahns wrote: >>> GCC doesn't generate binaries or shared libraries, ld does. Passing >>> -Wl,-rpath,/path/to/dependency/lib >> But this is not automatic. When typing >> $CC program.c -o program -lmpfr -lgmp >> (where $CC can be gcc, tcc or icc, for instance), things should just >> work, i.e. the correct options should be passed to ld *by default*. > That would be nice, on AIX directories passed with -L are also added to > the run-time library search path. This approach has serious drawbacks, though. Often, binaries are built against libraries in temporary staging areas (this is particularly common when installing into AFS file systems, but it comes up in other cases as well), and AIX's behavior, unless managed very carefully, can create serious security holes by looking in those directories for libraries by default. This is the reason for the libtool relink after install step, which isn't necessary on Linux but is vital on platforms that have AIX-like behavior (and has various issues of its own). There is no solution to this problem that works for every common binary building scenario. Both the approach of only searching system library paths by default and the approach of embedding paths to the linked libraries by default has serious advantages in some situations and serious drawbacks in other situations. For better or worse, Linux has standardized thoroughly on only searching system library paths regardless of where the libraries were when linked unless explicitly configured otherwise with -R, -rpath, or LD_RUN_PATH, and now lots of other tools expect and manage that behavior. Changing it would break things, rather horribly. (This is somewhat afield of the original issue, though, which was a change from RPATH to RUNPATH, and does sound rather surprising.) -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Colons not escaped for setting LD_LIBRARY_PATH.
Philipp Thomas writes: > The wrapper script created by ltmain 2.4.6 on Linux sets LD_LIBRARY_PATH > as an absolute path. Unfortunately it doesn't escape colons and the > colon is the delimiter for paths in LD_LIBRARY_PATH. So the exe doesn't > find its library. > Could someone help me locate the place where I could modify the escaping? Is it possible to escape colons in LD_LIBRARY_PATH? I did not believe it was, and a bit of research seems to support that. I believe directory names including colons are simply not supported for LD_LIBRARY_PATH (and various other things, such as PATH). -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: transitive shared library dependencies and installation
wf...@niif.hu writes: > Bob Friesenhahn writes: >> That sounds like a great idea. However, there is a problem that >> linking on some systems does depend on already installed libraries (or >> will end up using them) and so the libraries need to be installed and >> linked in a particular order. > Do you happen to know which systems these are? Where are these > constraints documented? It's been a very long time since I've built shared libraries for any platform other than Linux, but my distant recollection is that AIX and HP-UX encoded the full path to the dynamic library against which a binary was linked. Therefore, if you built an executable against uninstalled libraries, the executable would have a reference to the build directory, hence the explicit relinking step after installation to pick up the new paths. I seem to recall that we caused an outage for campus AIX systems because of this; I'm less sure about HP-UX. I don't remember whether this also applied to interdependencies between shared libraries (or if those platforms even supported encoding dependencies in shared libraries; a lot of platforms didn't). I vaguely recall that mutually-dependent shared libraries were actually impossible on at least some UNIX platforms, and thus not portable. Note that AIX is very, very different than ELF-based UNIX systems (which include Linux, Solaris, and I believe many of the BSDs) in how it handles both shared libraries and system calls. AIX shared libraries are quite unusual. I distantly recall that they're ar archives that contain a special object file named shr5.o or something like that? Both Tru64 and IRIX also had some odd linking behavior; I don't remember if they would have had similar issues. At the time, at Stanford we made the decision to build all binaries static on all platforms other than Solaris and Linux because the shared library behavior on other platforms was so odd and surprising that we weren't confident we would get the details correct and avoid introducing weird bugs. It's of course an open question how much any given project cares about supporting those UNIX variants these days. Some of them are still sold today, but the market share is quite small; others are varying degrees of obsolete. But that was the problem Libtool was originally written to solve, and is why it does so many things that on Linux are weird and unnecessary. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Re: transitive shared library dependencies and installation
Roumen Petrov writes: > Urgh, article with very limited niche. First is only for shared libraries, > next unresolved externals in shared library, and finally requires > "advanced" loader. Overlinking isn't about unresolved externals in shared libraries. It's about avoiding linking with shared libraries that *don't* resolve any external symbols. It doesn't require an advanced loader, just any reasonably modern shared library system; Solaris 2.6 from many years ago had the same issue. It is specific to systems where the linker is willing to encode dependencies to libraries (in NEEDED, for instance) that aren't actually required, but that's the default behavior of, say, GNU binutils. The standard problem is that liba depends on libb, and a binary depends on liba (but not libb). Libtool's default behavior in the presence of *.la files will link the binary with both liba and libb, even though it only needs to be linked with liba. This causes a lot of problems for the dependency management in a distribution if allowed to happen archive-wide, since it creates tons of unnecessary dependency edges that make dependency resolution and archive management much harder. Avoiding *.la files solves most of this. --as-needed helps when the upstream Makefiles are designed to support static linking (where all the libraries have to be listed), or where upstream just didn't pay attention to this or didn't consider overlinking to be a problem, but has been known to have bugs where it leaves out dependencies that actually are required. For the software I personally maintain, --enable-reduced-dependencies changes the behavior of Autoconf macros to not add the full transitive set of libraries and instead only link with the immediate dependencies. But I think I'm the only person who uses that convention. For newer software that uses pkg-config, pkg-config supports this inherently if the library maintainers write correct pkg-config files (which a lot of them don't). The article may have limited applicability in the grand picture of all systems and all ways of linking libraries, but it applies to pretty much every Linux distribution (and probably any other distribution of any kind of UNIX that uses shared libraries and package dependencies). So by quantity of Libtool installs and invocations, it's significant. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Re: cryptic "command not found" error
swedebugia writes:
> I have an issue with libtool. see details here:
> https://labs.parabola.nu/boards/5/topics/562
> I'm guessing my environment is broken somehow, but I cannot find any
> information on how to effectively debug this situation.
> The error from libtool does not help at all. Which command? What did it
> try to do?
The error message is:
CC mu-str.lo
../../libtool: line 3470: -v: command not found
The command not found is "-v". libtool is reporting that it's trying to
run a command named literally "-v", which of course was not found.
Looking at the dump you posted of your environment, this lept out at me:
MV=-v
I'm not sure why you set that environment variable, but I believe it is
overriding libtool's $MV variable because of this code:
# All uppercase variable names are used for environment variables. These
# variables can be overridden by the user before calling a script that
# uses them if a suitable command of that name is not already available
# in the command search PATH.
# ...
: ${MV="mv -f"}
and libtool is then running -v instead of the mv command because you are
telling it to do so with that setting. This of course doesn't work, and
as a result files are not moved to their correct locations during the
build.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Re: New libtool maintainer
Alex Ameen writes: > For the non-Linux patches I can merge them, but I don't have personally > have OSX, powerpc, or Solaris boxes, and while I do have a Windows > partition I don't currently have it set up to run these kinds of > tests. Nonetheless I can merge these - if you have access to any of > those platforms let me know if you would be open to running `make check' > and posting the logs so I can sanity check the new behavior. For testing INN builds on non-Linux, non-x86 platforms, we use the GCC Compile farm project: https://gcc.gnu.org/wiki/CompileFarm I am certain they would be happy to give you access as Libtool maintainer. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Re: Alternate SONAME values
Ganesan Rajagopal <[EMAIL PROTECTED]> writes: > I didn't know this. But trying to make -version-info get the SONAME you > need is an abuse of libtool in any case. I think -version-number option > available in recent versions of libtool is perfect for this. When introducing libtool with a libraries like X that have a well-established SONAME, one does not get to change the SONAME just because new applications using libtool shouldn't try to override the SONAME. It may be libtool abuse in a new application with no established library versioning, but for X, it's the difference between a working build system and a broken build system. There are ten-year-old binaries that expect a particular SONAME for the X libraries and can't simply be rebuilt. It's very, very important that they not break. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: noinst_bindir
Bob Rossi <[EMAIL PROTECTED]> writes: > I have > noinst_bin_PROGRAMS = gdbmi_driver > noinst_bindir = $(top_builddir)/progs Try using $(abs_top_builddir) instead. I've always had bad luck with relative paths and anything that involves libtool. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: noinst_bindir
Bob Rossi <[EMAIL PROTECTED]> writes: > noinst_bin_PROGRAMS = gdbmi_driver > noinst_bindir = $(abs_top_builddir)/progs > Unfortunatly, that doesn't work either. > test -z "/progs" || mkdir -p -- "/progs" > mkdir: cannot create directory `/progs': Permission denied Well, that makes it look like abs_top_builddir isn't actually getting set. I'm not sure exactly what would cause that. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dependency_libs?
Andreas Volz <[EMAIL PROTECTED]> writes: > I build my library with GNU autotools and link to it with the pkg-config > --uninstalled option without installing it. In this case a la-file > (libmhgui.la) is created. I've some problems to understand how libtool > generated the dependency_libs field. In my package is a > --with-x/--without-x option from AC_PATH_X. But the la-file has the X > libraries in its dependency_libs field. So how does libtool generate > this field? Well, you say that the correct field is: > # Libraries that this one depends upon. > dependency_libs=' /home/andreas/src/MakeHuman/cvs/animorph/src/libanimorph.la > -l glut -lGLU -lGL -lpng I expect that one of glut, GLU, and GL depend on the X libraries, and hence when libtool resolves transitive dependencies through the .la files, it pulls in the other libraries. This is one of the problems with .la files currently. It doesn't have the correct semantics to distinguish between static builds (and builds on platforms with deficient shared library handling) where all transitive dependencies have to be pulled into the link line and shared builds on modern platforms where transitive dependencies do not have to be pulled in and in fact generally *shouldn't* since they make library migrations harder. pkg-config does have this logic and some packages have started not installing libtool .la files and recommending that people just use pkg-config to get the right link lines to avoid this. That being said, the addition of extra dependencies is generally only a problem if you're building OS packages and have to be careful about adding too many dependencies. If you're just building software for local use, it doesn't really matter. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > Operating systems with robust library dependency support don't like the > libraries explicitly specifying dependendies on libraries they are not > immediately dependent on. Libtool has been specifying the full list of > dependencies to the linker, as it finds them in the .la files. And mostly because, unlike pkg-config, libtool doesn't distinguish between dependencies required for static linking and dependencies required for shared linking. > You may see that autoconf encourages configure scripts to supply all of > the library dependencies since the tests require it. Except in practice the tests don't on systems using shared libraries and shared linking with reasonable shared library dependency support (the default most places now). > Likewise, libtool applies all of the libraries it is instructed to apply > as well as additional dependencies obtained via the .la files. A > smarter build system would allow libtool to distinguish between > immediate dependencies and "extraneous" dependencies and only apply the > immediate dependencies if the OS/linke support it. That would be very nice. It does require input from the person building the library, though, or very recent GNU ld with options that don't work properly on some more obscure platforms. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > On Mon, 3 Jul 2006, Albert Chin wrote: >> Is libneon a static library? If not, and libneon has the 3rd-party >> libraries as dependencies, why shouldn't linking with just -lneon >> work? > As you are well aware, this only works on systems where the linker > applies implicit dependency libraries during linking. Failure results > when a shared lib does not specify any dependencies, or the OS does not > support it. > For example, specifying just -lpng might not cause the linker to > implicitly add -lz. Note that the linker that needs to figure this out is actually the dynamic linker as such dependencies should be resolved at run-time, *not* at link time. A linker that does such resolution at link time actually re-adds most of the problems that libtool currently causes. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removing rpath from libtool
"BRIAND, Michel M" <[EMAIL PROTECTED]> writes: > I would like to know why LD_LIBRARY_PATH is evil. There are many reasons, but one of the biggest ones is that it's a giant hammer that affects every binary that you run with it set. Even if you only set it in a wrapper script, it affects every program run by that program. So you end up having it affect programs that you don't expect, which as soon as you have multiple copies of libraries installed in different places can cause serious problems. It's very common for people using LD_LIBRARY_PATH with some libraries installed in one of those paths (such as new SSL libraries) to have system-provided binaries start failing in weird ways because LD_LIBRARY_PATH overrides the default search path for those binaries as well and points them at shared libraries that you aren't expecting. rpath is specific to one executable or library, and hence is much more targetted and doesn't have the same far-reaching effect. LD_LIBRARY_PATH can be used safely and many large installations do use it safely, but it's dangerous and tricky. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool modules and symbol clashes
"Simon White" <[EMAIL PROTECTED]> writes: > However if one of those modules internally calls a function that is also > marked as being exported it does not necessarily call the function in > its own library. Depending on order it may call the function that > exists in the other library instead. Note that both modules are only > manually loaded and neither are loading symbols from each other. It may (or may not) help as a workaround to build your modules with -Wl,-Bsymbolic, which tells the linker to bind all symbols locally within the shared object if possible at link time. This will (hopefully) cause the module to be built without an external reference to that symbol, so then there's nothing to go wrong at runtime. Note that this will change other linker behavior. Read the GNU ld documentation for more details on exactly what the option does. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
"Dan Nicholson" <[EMAIL PROTECTED]> writes: > Looks like I didn't look closely enough. For sure fedora removes all > the .la files unless there is a specific reason to need them. I > thought debian was too, but it looks like they keep them. My fault. Debian decides this on a maintainer-by-maintainer basis. Usually Debian keeps them until they cause problems and then removes them. They often do cause problems, so many library dev packages (but not all) don't include them any more. The most frequent problem caused by *.la files is that they add a pile of unnecessary dependencies to shared libraries, which further entangles package dependencies and makes upgrades unnecessarily hard. (This is the long-standing problem of including all dependencies required for static libraries, which aren't needed for shared libraries on systems that handle transitive dependency closures when loading shared libraries.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hello Russ, > * Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET: >> The most frequent problem caused by *.la files is that they add a pile >> of unnecessary dependencies to shared libraries, which further >> entangles package dependencies and makes upgrades unnecessarily hard. >> (This is the long-standing problem of including all dependencies >> required for static libraries, which aren't needed for shared libraries >> on systems that handle transitive dependency closures when loading >> shared libraries.) > Which is nicely solved with --as-needed, as long as you don't need to > stick in extra, seemingly-unneeded library dependencies that only become > useful for dlopen'ed modules. Debian's experience to date is that --as-needed is buggy and breaks a lot of software, and overall is not a particularly stable solution. Removing *.la files so that the unneeded shared libraries aren't linked in the first place works considerably better at the moment. For me, it's not a religious argument. I just want to do something that works on the platforms that Debian supports for a Debian package and removes unnecessary shared library dependencies. Currently, removing *.la files does and --as-needed doesn't always. (Note that personally I keep *.la files unless there's a specific problem that comes to light that I'm trying to fix, and would recommend that others generally do the same thing. I'm not advocating Fedora's approach; I think they're occasionally useful, particularly if you care at all about static linking.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Roumen Petrov <[EMAIL PROTECTED]> writes: > Russ Allbery wrote: >> Debian's experience to date is that --as-needed is buggy and breaks a >> lot of software, and overall is not a particularly stable solution. >> Removing *.la files so that the unneeded shared libraries aren't linked >> in the first place works considerably better at the moment. > Could you point by example how libtool add "pile of unnecessary > dependencies" ? Whit this example could you confirm that libtool add > more(extra) libraries then specified by project authors ? When you create a libtool library, libtool records every library against which that library was linked into the *.la file. If you then link another shared library against that shared library using libtool, libtool reads that list of libraries from the *.la file and links the new library against them as well. This is not necessary. For distribution packages, it's actually harmful. To see why, consider some library libfoo which uses readline. Suppose that libreadline is linked and installed with libtool, so it has a *.la file saying that it depends on libncurses. When you link libfoo against libreadline using libtool, libtool will also link it against libncurses, so it now acquires a dependency on libncurses as well. Now, suppose you're a distribution like Debian and you're upgrading the whole distribution to a new version of ncurses with an incompatible ABI. You have to rebuild every software package in the archive that's linked with libncurses. You therefore always have to rebuild readline. However, you *shouldn't* have to rebuild libfoo, since it doesn't call ncurses directly; it should be able to just pick up the new libreadline and be happy. But because of libtool's behavior, libfoo ends up depending (uselessly) on libncurses and has to be rebuilt as well. In a distribution as large as Debian, this has a significant impact. It causes a ton more work and makes library migrations much harder than they need to be. This situation is particularly bad for libraries that have a lot of dependencies, such as Gtk+. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Roumen Petrov <[EMAIL PROTECTED]> writes: > Russ Allbery wrote: >> When you create a libtool library, libtool records every library >> against which that library was linked into the *.la file. If you then >> link another shared library against that shared library using libtool, >> libtool reads that list of libraries from the *.la file and links the >> new library against them as well. > But problem is not in the libtool. Yes. It is. >> This is not necessary. For distribution packages, it's actually >> harmful. > This depend from platform. Yes. I said that. But it's harmful for the platforms that are in most common use (anything that uses ELF, for example). >> To see why, consider some library libfoo which uses readline. Suppose >> that libreadline is linked and installed with libtool, so it has a *.la >> file saying that it depends on libncurses. When you link libfoo >> against libreadline using libtool, libtool will also link it against >> libncurses, so it now acquires a dependency on libncurses as well. > This is one of the good samples. Libtool don't add dependency if is not > specified by project makefiles, i.e. LDFLAGS/LDADD. > But if readline project make rule specify that library has to linked > with a particular curses library, libtool has to use this rule, when > link an application with readline. Only on non-ELF platforms. > Also removing la-files won't help. My practical experience disagrees with your theory. > Libtool is for multi-platform use and list with complete dependent > libraries help me to build binaries on platform that don't support > unresolved symbols, as example windows. Yes, I understand why libtool does this in general. It's more portable. However, it causes practical problems for distribution packages, which is why distributors delete the *.la files to fix those problems in the absence of a better solution. Which is where this thread started. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Roumen Petrov <[EMAIL PROTECTED]> writes: > It was old build bug when building readline library on some linux-es. In > my memory is suse 7.1 but I'm sure that only this particular version was > affected. > Many other linux verdors build readline without dependent libraries and > this allow application to be linked against different curses compatible > libraries. libreadline is linked against libncurses on Debian. But surely it's obvious that this isn't an interesting argument and has nothing to do with my point? It may be that my specific example doesn't apply on the system that you're looking at right now, but I'm sure that you can find dozens or hundreds of others without even trying. Any shared library that is linked with other shared libraries and is built with libtool can present this problem. The best practice for distribution-packaged shared libraries and binaries is that they should only be linked against shared libraries whose ABIs they use directly. They should never be linked against shared libraries that they use only indirectly, since doing so adds unnecessary dependencies and unnecessary rebuild work when the SONAMEs of those additional shared libraries change. The same issue applies to any large local software installation. libtool does not follow this best practice unless you delete the installed *.la files or use --as-needed (which as a linker flag doesn't seem to be reliable or robust as yet -- I do apologize if --as-needed referred to some libtool-specific feature I didn't know about instead of the GNU ld flag). One of the problems with the GNU ld --as-needed flag is that it applies indiscriminately to all linked libraries, even ones that the application maintainer added explicitly (rather than being added implicitly by libtool), and sometimes does the wrong thing with libraries that are actually needed. The desired behavior of libtool from a distribution perspective would be to not include dependency libraries from the *.la file in the link on platforms known to have proper transitive dependency support unless a static link was requested. (There would need to be a flag to override this for the unusual cases where this is required; there are some edge cases where it's needed, usually involving things like weak symbols or other corner cases.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Roumen Petrov <[EMAIL PROTECTED]> writes: > Russ Allbery wrote: >> libreadline is linked against libncurses on Debian. > Which version ? readline 5.2-3, ncurses 5.7-2. > This is an 7(5?) years old linux bug. I'm very dubious of that assertion. Applications which use readline but do not directly use any curses functions should not need to link with any curses library. > Details: > - library foo1 for pkg1 export function foo1 > - library foo2 for pkg2 export function foo2 and use function foo1 > - application use functions foo1 and foo2 and and to link with libraries > that export them. > > Where is libtool bug ? Your example as described above has nothing to do with the case that we're talking about since it contains no implicit dependencies. I'm afraid I can only conclude that I've not been sufficiently clear and you're not following my point at all. I've explained this as clearly as I can, though. Maybe someone else can do a better job. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > Quite a lot can known from .la files but it is apparent that .la files > are now spontaneously deleted. Hm, I must admit that I generally find them useless compared to reading readelf -a output, but I'm not the normal user. :) > It is really quite a burden on the developer to try to understand what > is needed for static and shared linking. Many Linux application/library > authors are not even aware of all the libraries they are using and it > might not be possible to fully know without using diagnostic tools, > special environment variables like LD_BIND_NOW, or a particular > execution mode of the software. Dependencies are not always obvious and > is is possible for "pass through" dependencies to be introduced > (stealthy hard dependencies) that the developer is not aware of. This is all true in the general case, but most of the cases where clients of a library need to link against that library's dependencies are weird edge cases. My guess is that only linking with the libraries whose ABIs you call directly works 95% of the time on modern ELF platforms, and linking with -pthread where appropriate is the only additional bit required in another 4% or more of the cases. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > It seems that there is an issue for Linux distribution maintainers. What > needs to be done about it so that this topic does not come up so often? Well, my preference would be to implement the change to libtool described in my previous message, but since that had been proposed many years ago and was not done, I assume that there's some reason why it's a bad idea that I'm not aware of. pkg-config supports having separate dependency lists for static linking and shared linking, which seems to adequately address this problem (if that feature is actually used; the documentation last I looked was a bit lacking and a lot of pkg-config *.pc providers aren't aware of it). libtool could do something similar, but there would have to be some way to tell libtool which libraries are required for shared linking and which are required only for static linking. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Dependencies with static library
"Erich Hoover" <[EMAIL PROTECTED]> writes: > I have an application (A) that depends upon an obscure library made by > me (B), that depends on a slightly less obscure library made by someone > else (C). I would like to compile A with "B" as a static library so > that the user does not need to install it separately, but when I do this > the compilation does not pull in the library "C" into the mix and has > undefined references to all of the functions it needs. Is there any > easy way for me to fix this without having "A" know about the dependency > on "C"? Is (B) also linked with libtool? If so, is the *.la file installed? That's where libtool gets the metadata required to know when to link to additional libraries. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Bob Friesenhahn writes: > On Tue, 25 Aug 2009, Anssi Hannula wrote: >> I think the proper way to solve this is to not link to dependency_libs >> when linking dynamically on systems where it is not needed to link to >> those. I haven't seen any correctly working patches that implement >> this. > Relying on the OS's implicit dependency features seems to be an approach > which is fraught with peril. Relying on the dynamic linker to resolve implicit dependencies is the only way that it's really feasible to maintain a distribution the size of Debian. Otherwise, your shared library dependencies get so entangled that it's extremely difficult to correctly handle transitions. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Bob Friesenhahn writes: > On Tue, 25 Aug 2009, Russ Allbery wrote: >>> Relying on the OS's implicit dependency features seems to be an >>> approach which is fraught with peril. >> Relying on the dynamic linker to resolve implicit dependencies is the >> only way that it's really feasible to maintain a distribution the size >> of Debian. Otherwise, your shared library dependencies get so >> entangled that it's extremely difficult to correctly handle >> transitions. > Note that program/library linkage and the dynamic linker are two > entirely different things. Libtool only takes care of the former, > although it may run ldconfig to assist with the latter. I know what the difference is. My point is that adding an explicit dependency on a shared library whose ABI you do not use directly simply doesn't scale when maintaining a distribution the size of Debian. You have to rely on the dynamic linker to resolve transitive dependencies. I mention the dynamic linker because one of the reasons why libtool has this feature is for platforms where the dynamic linker *cannot* resolve transitive dependencies and needs the binary to be linked against all shared libraries, including ones only used indirectly. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Bob Friesenhahn writes: > How would you like to deal with the case where a library has multiple > usable dependencies, which satisify identical purposes, but via > different possible libraries? > libfoo-ssl_fast.so > myprog --> somelib --> or > libfoo-ssl_slow.so > Note that in this case myprog depends on somelib and so that is an > explicit dependency. However somelib needs some symbols from a library > that the user selects at link time. In this one particular case, an explicit dependency seems reasonable. This case is exceptionally rare. In all the years that I've worked on free software and packaging of software for multiple different versions of UNIX, I've never wanted to do this, and I don't know of any case in the thousands of packages in Debian where this technique is used. Normally it's easier and more robust to just build two different versions of somelib, one for each of the alternative dependency libraries. (See, for instance, how cURL is handled in Debian.) -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Ralf Wildenhues writes: > * Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST: >> Is someone here willing to contribute a portable m4 macro which tests >> the compiler (and/or linker) to prove beyond a shadow of a doubt that >> it adequately supports the implicit linkage required? The tests should >> work for more than Linux and should be based on observed behavior. > Is support in Debian full now? Do dlopen'ed modules that have indirect > dependencies outside of default-searched library paths get loaded > correctly now, with DT_RPATH entries only pointing to direct deplibs > (and recursively for their DT_RPATH entries)? This particular scenario I've not checked personally. I never use non-default-searched library paths for anything. I certainly agree that libtool needs to support that case, though. dlopened modules are something of a special case; it's one of the places where Debian may not remove *.la files depending on the specific situation. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Ralf Wildenhues writes: > * Russ Allbery wrote on Wed, Aug 26, 2009 at 07:35:53AM CEST: >> dlopened modules are something of a special case; it's one of the >> places where Debian may not remove *.la files depending on the specific >> situation. > I have a question here, since it seems some of the involved people are > reading: is there a chance distributions would re-add .la files if the > indirect deplib linkage issue is out of the way? So far as I know, that's the only thing that's driving Debian this direction right now. I think there may be some reluctance to re-add them without an understanding of why they're useful for system libraries that come with the distribution, since there's a general perception right now that on a Linux system they're mostly useless, but I think people are open to being convinced there. The only *problem* that I'm aware of them causing at the moment is the increased shared library dependencies. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tries to link against uninstalled libs
mega...@gmail.com writes: > I am trying to compile cfengine 3.03 under Solaris10/SPARC. My system > previously had a large number of Sun Freeware packages (which install > under /usr/local/) that have now been removed. > However, during link libtool carps with the following errors: > grep: can't open /usr/local/lib/libfontconfig.la > Can't open /usr/local/lib/libfontconfig.la > libtool: link: `/usr/local/lib/libfontconfig.la' is not a valid libtool > archive > Cfengine does not link against fontconfig, however fontconfig was one of > the packages that was previously installed then removed. I cant work out > why libtool is trying to link against a library that is not being used or > mentioned in the package being built. It's linking against some other package which has a *.la file that mentions fontconfig. Grep for fontconfig in the *.la files of all your installed libraries. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
Ralf Wildenhues writes: > My problem with that change is that, the relinking and finish really are > information that some users need to know about. If you don't --finish, > then your libraries won't be found by the runtime linker. If relinking > happens as another user than the one who ran `make all', that is a > problem to know about, too, because it can lead to problems with file > ownership and directory write permission. Perhaps libtool could add some more logic around when that text is displayed? It's always been noise for me; I've never needed to run --finish despite the message, presumably because of the platform on which I'm running libtool. If libtool could suppress that message unless the platform actually needs to do something at --finish, that would probably solve the problem. That would also solve the problem of people like me who are so used to that message and so used to it being useless that we've mentally filtered it out and wouldn't see it even if we needed to. On Linux, all that --finish appears to do is update the library symlinks. I don't understand why libtool thinks that needs to be done, given that it installs the library symlinks itself properly in the first place. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Library coding standards question
jks <[EMAIL PROTECTED]> writes: > "Choose a name prefix for the library, more than two characters > long. All external function and variable names should start with this > prefix. In addition, there should only be one of these [one name prefix, > one external function, one variable name, or one of something else?] in > any given library member [what is the meaning of "library member" in > this context?]. This usually means putting each one [one what?] in a > separate source file." Only one of each external function or variable name, and library member is generally an individual .o file. The reason to put only one external function in each .o is that linkers generally can only shed unwanted baggage at the level of individual .o files, and therefore if something in a .o file is needed, the whole file will be linked in. This guideline is therefore intended to minimize the size of statically linked binaries by giving the linker maximum freedom to drop unused code. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Earnie Boyd <[EMAIL PROTECTED]> writes: > Two wrongs a right does not make. I.E.: I believe it wrong for any > maintainter to not move forward with the current versions of autotools > regardless of the maintainer's reasons for not doing so. That comes across as pretty arrogant. autoconf 2.5x was a disaster for some projects. That it was a disaster because autoconf 2.13 was woefully inadequate and therefore they had to do things they shouldn't have to do to accomplish what they needed to accomplish doesn't change the fact that autoconf 2.5x was a disaster and represents a vast amount of work that would have to be done. Many projects have other priorities, since after all autoconf 2.13 was working for them. The vast majority of packages using autoconf have not updated to autoconf 2.5x in my experience with compiling software. > FWIR, Akim and other developers tried hard to maintain [back|bug]ward > compatibility. Um, no. I have a lot of respect for Akim and the other autoconf 2.5x developers and what they've tried to accomplish, but it's very clear that backward compatibility was not an important goal. I highly doubt that any even moderately complex autoconf 2.13 configure script will work in autoconf 2.5x unless it was written by Akim. There were a variety of reasons for breaking backward compatibility, like choosing to clean up quoting, but that's a justification for doing it, not an argument that it didn't happen. It very clearly did happen. Calling the autoconf scripts that worked in autoconf 2.13 but not in 2.5x "broken" is a deflection that I'd be more sympathetic to if the ways in which they were "broken" were clearly documented in autoconf 2.13, but they weren't. Which means that the language definition was changed (to something much more precise, mind), not that scripts that followed the previous language definition such as it was were broken. All that being said, I believe that the direction taken with 2.5x was more right than wrong. Certainly it's a lot more pleasant and a lot clearer to write configure scripts using the new language definition than the old one because it's much clearer what to do at any given point to accomplish what you want to accomplish (although the annoying cache directory and the speed issues are a bit frustrating). But it wasn't a backward-compatible change. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Akim Demaille <[EMAIL PROTECTED]> writes: > If people consider we deliberatedly broken bugward compatibility, then > fine, you're free to be wrong. It's not what happened (and I can tell > you that a lot of code would not have been written if that was our > intention), but I don't care what people think wrt this now, because... For what it's worth, I don't think you deliberately broke it, and I'm not arguing intentions at all. I'm just trying to relate how it looks from entirely outside the project, when the only information one has to go on is how Autoconf 2.13 works and how Autoconf 2.54 works. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Soren A <[EMAIL PROTECTED]> writes: > Echo. I don't dispute that Bob might be correct but TTBOMK this is not > _common_ knowledge. After extensively messing around with building a > libtool from GNU cvs within the last 3 weeks, I can say that I see no > means by which libtool can readily be used anymore without Autoconf and > Automake being involved. I can't comment on using it without Autoconf, but INN uses libtool and doesn't use Automake. That's not particularly difficult to do, at least for the simple cases. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: no AIX 5 support? I've got some idea what's needed.
Gary Kumfert <[EMAIL PROTECTED]> writes: > Maybe someone knows a reason why I can't simultaneously have static *.a > and dynamically loadable *.so on AIX... just like I do for > Linux/Solaris? If so, I'd like to understand why. AIX traditionally uses a completely different library format than other systems. Both the shared and the static objects are supposed to go into the same .a file, and the linker will chose whichever is appropriate. This means that .a files on an AIX system may be used at runtime and may actually be shared libraries. I don't know how much of that, if any, AIX 5.x changed. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltmain.sh and configure
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > I have a copy of libtool-1.5.tar.gz which was retrieved on April 15. > The MD5 checksum is also "0e1844f25e2ad74c3715b5776d017545". I have a copy dated April 14 with the same MD5 checksum. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > The issues I mention are primarily philosophical and religious. There > is a subversive element of open source society that is willing to use > Autoconf and Libtool, but not Automake. The FreeType and libJPEG > projects come to mind. Yup, I'm in that category too. Automake makes a bunch of assumptions about how a package will be organized, requires one generate all of one's Makefiles with configure (thus making the configure step and rerunning config.status just painfully slow), works poorly with non-recursive make, and generates incredibly ugly and unreadable Makefiles and compiler output. It does a lot of nice things too, but if you already have a build system that works, switching to Automake doesn't really have a lot of justification and has definite drawbacks. libtool, on the other hand, is pretty easy to just drop in to a regular Autoconf with hand-written Makefiles environment (I've done so on several occasions). > If AM_INIT_AUTOMAKE is used, then Automake must be installed in order to > maintain the package, even if the dependent package uses JAM, GNU make, > BSD make, Imake, or hand-coded traditional make. This I'm not too worried about. I generally have Automake around. Just as long as I don't have to use Automake for the package itself when I use libtool, I think this is fine. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool source?
Nick Twaddell <[EMAIL PROTECTED]> writes: > How long till the libtool source is posted back on the site? Looks like it's there now. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.5.2 searches /usr/lib before -L
Pieter Grimmerink <[EMAIL PROTECTED]> writes: > OK, now I've given the library in -L a .la file as well. Now both > libraries have a .la file, and libtool-1.5.2 uses the correct library, > in -L. So that's solved then. So, basically, it sounds like libtool has reinvented the very annoying Tru64 library search mechanism, where any shared libraries are found before static libraries regardless of the relative order on the library path, except as applied to *.la files. This sounds like a bug to me. The Tru64 behavior causes no end of surprises and means that you can't easily link with (often newer) locally installed static libraries if the operating system happens to come with some dynamic library by the same name. What was the reason for this change, or was it accidental? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
