hardcode_shlibpath_var bogosity

[Ralf Wildenhues]

This is my third attempt at a summary of the problem.

Quoting libtool.info
| -- Variable: hardcode_shlibpath_var
|     Set to `yes' or `no', depending on whether the linker hardcodes
|     directories by writing the contents of `$shlibpath_var' into the
|     resulting executable when HARDCODE_LIBDIR_FLAG_SPEC is specified.
|     Set to `unsupported' if directories specified by `$shlibpath_var'
|     are searched at run time, but not at link time.

This is our definition of the variable, and its use in both
tests/hardcode.test and ltmain.in match this definition.
(Similarly with CVS HEAD).

Issues:
1) There is no default value for the CXX tag (should be unsupported).
   Trivial bug.

2) There is no system on which this is `yes'.  Weird, huh?  ;-)
   The only mention of a supposedly matching system I could find: [1]
   (to me, dubious at best whether this was a bug).

3) There are quite a few systems which have a `no' here, but the 
   corresponding hardcode.test bit fails: basically all that use GNU
   binutils ld, at least.  They would pass if set to `unsupported'
   instead (some BSD versions fall in this category).

I guess the `no' rather than `unsupported' is because of this (quoting
ld.info):
| `-rpath-link DIR'
|    When using ELF or SunOS, one shared library may require another.
|    This happens when an `ld -shared' link includes a shared library
|    as one of the input files.
|
|    When the linker encounters such a dependency when doing a
|    non-shared, non-relocatable link, it will automatically try to
|    locate the required shared library and include it in the link, if
|    it is not included explicitly.
[...]
|
|    The linker uses the following search paths to locate required
|    shared libraries.
[...]
|      5. For a native linker, the contents of the environment variable
|         `LD_LIBRARY_PATH'.

But there is a slight difference here: GNU ld uses LD_LIBRARY_PATH to
search for any libraries *DT_NEEDED* by other libraries only, not for
any libraries specified on the command line!  Actually, it's even
trickier: If you specify this library on the command line, ld will
complain and exit with nonzero status, but *still* pick the library up
from the other one through DT_NEEDED + LD_LIBRARY_PATH, and also *still*
create a working executable!

At the end of this post are tests to demonstrate this, if you found above
explanation incomprehensible.


I believe we should make a decision here eventually:

- either we set this to unsupported for all use of GNU ld and
  descendants,

- or we go a step further and just remove the variable completely;

- or we change the meaning of the variable (and maybe also its name)
  so that it can actually be useful (and be `yes' for GNU ld).
  I'm not yet convinced that an actual usage pattern may emerge,
  though.  For Debian's link_all_deplibs=no[2], it may yet prove useful.

Thoughts?

Cheers, and yes, all of this is post-1.5.22,
Ralf

[1] http://lists.gnu.org/archive/html/libtool-patches/2001-02/msg00019.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320698
[3] 
mkdir .libs
echo 'int x=0;' > a.c
gcc -c -fPIC a.c
gcc -shared -o .libs/liba.so a.o
echo 'extern int x; int main(void) { return x; }' > m.c
gcc -c m.c
LD_LIBRARY_PATH=./.libs gcc -o m m.o -la
| /usr/bin/ld: cannot find -la
| collect2: ld returned 1 exit status
ls m
| ls: m: No such file or directory

[4] 
mkdir .libs .libs2
echo 'int x=0;' > a.c
gcc -c -fPIC a.c
gcc -shared -o .libs/liba.so a.o
echo 'extern int x; int y(void) { return x; }' > y.c
gcc -c -fPIC y.c
gcc -shared -o .libs2/liby.so y.o -L.libs -la
echo 'extern int y(); int main(void) { return y(); }' > m.c
gcc -c m.c
LD_LIBRARY_PATH=./.libs gcc -o m m.o -L.libs2 -ly
objdump -p m | egrep 'NEEDED|RPATH'
|  NEEDED      liby.so
|  NEEDED      libc.so.6