Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results
After removing LD from my environment: All 112 tests passed David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool-1.15.23b (amd64-unknown-freebsd6.2) check results
After unsetenv-ing my LD, the tests look much happier. ... SKIP: demo-nopic.test ... == All 111 tests passed (1 tests were not run) == David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: hello-project install failure
Ok, I've figured out my problem. There is no proper curse in m4, perl, or bf for my stupidity. Apparently, some time ago, I thought it was a good idea to "setenv LD g++". (I was building others' non-autotoolized projects that mistakenly linked c++ objects using gcc or ld, which does not necessarily Do The Right Thing.) This had stayed in my FreeBSD environments for a few (4+) years and never done noticeable harm. A little research into my config.logs showed that LD is picked up from the environment in the configuration tests. From here on after (configure), everything gets screwed up, but in a subtle and stealthy way that triggered no visible failures until AFTER a built executable was executed from its installed home. (Even installcheck's that *ran* the installed executables did not fail, because the mistakenly referenced ".libs/libfoo.so" was still present from the working directory!) Many apologies for the noise in the last few days. I will re-run all libtool tests 'properly', and report any *real* problems if I find any. Lesson: don't setenv LD to workaround other's misuse of linkers. Fix their build systems instead. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool-1.15.23b (amd64-unknown-freebsd6.2) check results
> > Below is an excerpt from [g]make check of libtool-1.15.23b on > > amd64-unknown-freebsd6.2 (most PASSes omitted): > > > FAIL: hardcode.test > > FAIL: pdemo-make.test > > SKIP: pdemo-exec.test > > SKIP: pdemo-inst.test > [...] > > PASS: tagdemo-conf.test > > PASS: tagdemo-make.test > > FAIL: tagdemo-exec.test > > PASS: tagdemo-shared.test > > PASS: tagdemo-make.test > > FAIL: tagdemo-exec.test > > Please show verbose output for these test groups (see README for how to > do that). Thanks. Ralf, Attached (bz2). I've now noticed something VERY disturbing from the top-level config.log. On this amd64 host, there are no programs installed with suffix -3.4.0, and CC and CXX are unset in the environment. Yet configure picks up: configure:3919: checking for ld used by gcc configure:3986: result: g++-3.4.0 configure:3995: checking if the linker (g++-3.4.0) is GNU ld configure:4010: result: no Something is terribly wrong... I'm going to investigate further. I can also feel a big slap on my forehead coming... David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) libtool-amd64-freebsd62-check.log.bz2 Description: Binary data ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: hello-project install failure
Hello David, * David Fang wrote on Fri, Feb 23, 2007 at 11:02:55PM CET: > As mentioned from a previous thread, here's a link to a simple > shlib project: > http://www.csl.cornell.edu/~fang/sw/hello-autotools-0.1.tar.bz2 Thanks. I did this: bzip2 -dc hello-autotools-0.1.tar.bz2 | tar xf - mkdir build ../hello-autotools-0.1/configure -C make make install DESTDIR=`pwd`/DEST objdump -p DEST/usr/local/bin/hello-main | DEST/usr/local/bin/hello-main: file format elf32-i386-freebsd | [...] | Dynamic Section: | NEEDED libhello.so.0 | NEEDED libstdc++.so.5 | NEEDED libm.so.4 | NEEDED libc.so.6 | RPATH /usr/local/lib/hello-autotools | INIT0x80485e8 [...] on a i386-unknown-freebsd6.2 system. Looks all normal to me. Could you make your (non-ccache, please, for reproduceability) build tree and install tree of this package available as a tarball as well? Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results
Adding another datapoint: > I don't understand why this test fails though. Could you try without > ccache? Things should work with ccache as well, but it seems they > don't. The same tests on i386-unknown-freebsd4.3 were re-run *without* ccache, and gave the same results (some PASSes omitted). PASS: demo-shared.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test FAIL: hardcode.test PASS: pdemo-conf.test FAIL: pdemo-make.test SKIP: pdemo-exec.test SKIP: pdemo-inst.test PASS: tagdemo-static.test PASS: tagdemo-make.test PASS: tagdemo-exec.test PASS: tagdemo-conf.test PASS: tagdemo-make.test FAIL: tagdemo-exec.test PASS: tagdemo-shared.test PASS: tagdemo-make.test FAIL: tagdemo-exec.test 4 of 110 tests failed (2 tests were not run) Please report to bug-libtool@gnu.org It doesn't look like ccache is affecting these results. If you want a verbose log from this set, I can also provide. David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results
* David Fang wrote on Fri, Feb 23, 2007 at 10:26:06PM CET: > > This failure is because $LD is set wrongly, see the configure output > > earlier: > > > > | checking for ld used by ccache gcc-3.4.0... g++-3.4.0 > % ccache gcc-3.4.0 -print-prog-name=ld > ld Hmm. Do you have $LD set? Does ccache set this variable? Also I noted configure computes a dependency style of "none". Looks like another ccache-induced artifact I cannot reproduce here. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
hello-project install failure
Hi, As mentioned from a previous thread, here's a link to a simple shlib project: http://www.csl.cornell.edu/~fang/sw/hello-autotools-0.1.tar.bz2 which was just the product of "gmake distcheck". The project was libtoolized with version 1.15.22. The project works fine on all systems I've tested (linux, darwin) except FreeBSD (4.3, 6.2). The failure only occurs with trying to execute the installed binary, 'hello-main', from a shared-lib build (static builds are OK). The binary/objdump shows that the installed executable is still looking at the build path (.libs/libhello.so). As usual, let me know if you can reproduce it on a FreeBSD system, or you need more information about my configuration/environment, logs, etc. basics: on i386-unknown-freebsd: /usr/local/compiler/bin/gcc-3.4.0 % gcc-3.4.0 -v Reading specs from /usr/local/compiler/lib/gcc/i386-unknown-freebsd4.3/3.4.0/specs Configured with: ./configure --prefix=/usr/local/compiler --program-suffix=-3.4.0 --enable-shared --enable-threads=posix --disable-nls --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.0 sometimes using ccache, sometimes using distcc (no difference in result) MAKEFLAGS=-j2 LD_LIBRARY_PATH=/usr/local/compiler/lib on amd64-unknown-freebsd6.2: /usr/bin/gcc % gcc -v Using built-in specs. Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 no ccache, no distcc MAKEFLAGS=-j4 LD_LIBRARY_PATH=/usr/local/compiler/lib (non-existent path on this host) Hope we can figure this out. David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results
Hi Ralf, > * David Fang wrote on Thu, Feb 22, 2007 at 05:17:17AM CET: > > > > Here are my results for libtool-1.15.23b on > > > > i386-unknown-freebsd4.3 (most PASSes omitted): > > > Some relevant excerpts and notes: > > > > -->8 snip 8<--- > > = Finding libtool.m4's guesses at hardcoding values > > = Searching for hardcoded library directories in each program > > .libs was hardcoded in `hc-direct', as libtool expected > > .libs was hardcoded in `hc-libflag', as libtool expected > > `hc-libpath' was not linked properly, which fooled libtool > > .libs was not hardcoded in `hc-minusL', as libtool expected > > FAIL: hardcode.test > > Hmm. Let me know if there's some output I can provide to help there. > > -->8 snip 8<--- > > /ufs/vlsi/fang/freebsd/bin/bash ./libtool --tag=CC --mode=link ccache > > gcc-3.4.0 -g -O2 -no-undefined -version-info 3:12:1 -o libhello.la -rpath > > /tmp_mnt/cancun/home2/fang/local/src/libtool-1.5.23b/i386-freebsd4.3-build/tests/_inst/lib > > libhello_la-longer_file_name_hello.lo libhello_la-longer_file_name_foo.lo > > libhello_la-longer_file_name_foo2.lo -lm > > creating reloadable object files... > > creating a temporary reloadable object file: .libs/libhello.la-3.o > > g++-3.4.0 -r -o .libs/libhello.la-1.o > > .libs/libhello_la-longer_file_name_hello.o > > > > /usr/libexec/elf/ld: cannot find -lm > > collect2: ld returned 1 exit status > > The command should be something like > ld -r -o .libs/libhello.la-1.o .libs/libhello_la-longer_file_name_hello.o > > This failure is because $LD is set wrongly, see the configure output > earlier: > > | checking for ld used by ccache gcc-3.4.0... g++-3.4.0 > | checking if the linker (g++-3.4.0) is GNU ld... no > | checking for g++-3.4.0 option to reload object files... -r > > Please show the output of both of these: > gcc-3.4.0 -print-prog-name=ld > ccache gcc-3.4.0 -print-prog-name=ld % gcc-3.4.0 -print-prog-name=ld ld % ccache gcc-3.4.0 -print-prog-name=ld ld (same results for g++) ld --version GNU ld 2.10.1 Copyright 2000 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Supported emulations: elf_i386 Should it be something else? Is this a problem with configure-detection? > > === Running tagdemo-exec.test > > Executing uninstalled programs in ../tagdemo > > /usr/libexec/ld-elf.so.1: Cannot open "./.libs/libbaz.so" > > ../../tests/tagdemo-exec.test: cannot execute ../tagdemo/tagdemo > > FAIL: tagdemo-exec.test > > -->8 snip 8<--- > > This looks like the same failure I see on my own hello-world demo > > project: an installed binary linked to a shlib, still uses a hardcoded > > path to the *build* directory, not the install directory. > > No. The test is trying to execute an "uninstalled" program, you are > trying to execute an "installed" program. Different situation. > > I don't understand why this test fails though. Could you try without > ccache? Things should work with ccache as well, but it seems they > don't. Ok, firing up new round of tests without ccache... will update in an hour. I'll also post a tarball of my failing hello-world project shortly... David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
