On Sun, 13 Feb 2000, Matthias Drochner wrote:

> fb@enteract.com said:
> > we should be able to update libtool to libtool-1.3.4
> 
> I've just tried your updated package, and found that
> the new libtool doesn't pass its own selftests on
> i386/current/ELF.
> For mysterious reasons, many more tests pass if the
> "make check" is called with BSD make instead of gmake.

I just got "18 of 35 failed" on 1.4.2/i386 with gmake, but all 56
passed with make; on 1.4P/i386, 5 failed with make. The five that fail
on 1.4P are demo-exec.test X3, hardcode.test, and build-relink.test.

The problem seems to be that hardcoded, relative paths to shared libs
are interpreted by the run-time linker as relative to the current
directory, rather than relative to the binary. a.out had the same
problem with the ncurses demo programs (if you tried to install them).

The extra failures with gmake -may- be related. One thing gmake does
different is to run gcc without "cd" into the build directory first.

I suggest that if hardcoded paths to shared libraries are supposed to
work at all, as some packages clearly assume they do, it makes more
sense to interpret them as relative to the binary than to the current
directory. I could see where this could be useful. Consider that you
might want to link a package and it's libraries in place, and then
install the whole tree.