Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results

[David Fang]

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!)