Hi Jacob,
* Jacob Meuser wrote on Mon, Nov 28, 2005 at 01:03:56AM CET:
> On Sun, Nov 27, 2005 at 09:06:09AM +0100, Ralf Wildenhues wrote:
> >
> > Libtool knows that the library is uninstalled, because this information
> > is encoded in libbar.la
>
> yes, it winds up in $notinst_path. I disconvered that last night.
>
> > , hence knows to hardcode it _even_ when the
> > installed path is given first.
>
> I don't think that is the issue, or even what is wanted, though.
Right.
> > Attached an example. Please modify so it fails on OpenBSD.
>
> here's the change to run.sh. as I said earlier, this is a
> lot closer to what automake produces:
OK. This below should fail without changes (the earlier example linked
wrongly against the installed library, but that was not exposed because
both libs exported the same symbol names; the shell wrapper then set
paths accordingly so execution would use the uninstalled library):
- snip -
: ${LIBTOOL=libtool}
: ${CC=gcc}
instdir=`pwd`/inst
libdir=$instdir/lib
: ${LDFLAGS=-L$instdir/lib}
mkdir "$instdir" "$libdir" 2>/dev/null
echo 'int a() { return 1; }' > a.c
$LIBTOOL --mode=compile --tag=CC $CC $CFLAGS -c a.c
$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o liba.la \
a.lo -rpath "$libdir"
$LIBTOOL --mode=install cp liba.la "$libdir"/liba.la
$LIBTOOL --mode=clean rm -f liba.la
echo 'int b() { return 2; }' > a.c
$LIBTOOL --mode=compile --tag=CC $CC $CFLAGS -c a.c
$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o liba.la \
a.lo -rpath "$libdir"
echo 'extern int b(); int main() { return b(); }' > main.c
$CC -c main.c
$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o main \
main.o ./liba.la
./main; echo $?
- snip -
> see, if there is a liba.so.0.0 in /usr/local/lib it will get used
> instead of the one in /home/jakemsr/tmp/lt/inst/lib. quoting
> cc(1):
Right. Thanks for the quote.
> > I am pretty sure our testsuite covers this, too. Any failures on
> > OpenBSD? (Please run with VERBOSE=x so one can see actually useful
> > output.)
>
> i have previously reported all testsuite failures to the libtool lists.
> IIRC there were two, one I understood why and the other I didn't.
> no one seemed interested.
I am duly sorry. I for one simply don't have the resources to deal with
every bug reported, and the ones I don't understand or can't reproduce
are much harder to deal with than others. Could you please point me to
the reports, I have trouble finding them easily in my archive. Thanks.
> for completeness:
>
> puff:~/tmp/lt% libtool --config
*snip*
Thanks.
The way I see it, there are two possible ways out:
1) Move all paths to uninstalled libraries (in the correct order) before
all other path specs. This is pretty much in the spirit of the patch
you posted in the other mail to the ports list. It would need some
cleanup, and should probably be conditionalized on $hardcode_direct=yes.
Also, I think I would move the flags right when I encounter the libs,
not mangle them afterwards. (That would save us from needing .libs aka
$objdir as a criterion here.) Lemme see..
This approach comes with the minor danger that other libraries living in
those directories may be picked up; this _should_ not hurt, as all those
paths should be within the same package, or package tree, and the tree
should contain only desired libraries.
2) For systems with hardcode_direct=yes, require relinking upon
installation, and use the then-hardcoded paths for uninstalled dependent
libraries and programs, like this:
gcc -o main main.o -L$libdir ./libs/liba.so..
This would be safer in the sense that the chance of picking up wrong
libraries is minimized (but I still haven't grasped the exact semantics
of the linker when given a shared lib with a relative or absolute path).
OTOH, it would be slower, and I know users hate relinking.
Comments?
Cheers,
Ralf
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
