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
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
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 (i386-unknown-freebsd4.3) check results
Hello David, * 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. --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 === 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. 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
On Feb 22, 2007, at 8:38 AM, David Fang wrote: Hi again, Here are my results for libtool-1.15.23b on i386-unknown-freebsd4.3 (most PASSes omitted): Hi David, Hmm, all tests pass for me with i386-unknown-freebsd4.8. Please rerun the failing tests with VERBOSE=1 e,g: env VERBOSE=1 TESTS='hardcode.test pdemo-conf.test pdemo-make.test tagdemo-conf.test tagdemo-make.test tagdemo-exec.test \ gmake check And post the results. Thanks, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
