[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

hardcode_shlibpath_var bogosity

From: Ralf Wildenhues
Subject: hardcode_shlibpath_var bogosity
Date: Sun, 18 Dec 2005 13:53:10 +0100
User-agent: Mutt/1.5.9i

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

| -- 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 match this definition.
(Similarly with CVS HEAD).

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
| `-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

- 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.


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

mkdir .libs
echo 'int x=0;' > a.c
gcc -c -fPIC a.c
gcc -shared -o .libs/ 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

mkdir .libs .libs2
echo 'int x=0;' > a.c
gcc -c -fPIC a.c
gcc -shared -o .libs/ a.o
echo 'extern int x; int y(void) { return x; }' > y.c
gcc -c -fPIC y.c
gcc -shared -o .libs2/ 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'

reply via email to

[Prev in Thread] Current Thread [Next in Thread]