rpath semantics in binutils?

rpath semantics in binutils?

[Todd Vierling]

Not that this is directly related to egcs, but upon building and using a
cross compiler for SunOS 4.1.x SPARC, I found that GNU ld does the following
(rather odd, in my opinion) things with -L and -rpath for SunOS (sunos.em). 

- If -rpath is specified on the command line, no directories specified by
  -L are searched for shared libraries.  (They then have to be specified
  with -rpath-link.)
- The binary's rpath (list of runtime shared library search paths) is built
  from internal library paths (unless -nostdlib) and all -L options.  This
  is more than bogus for a cross-compiler, and IMHO, rpath should only be
  created if one is explicitly specified on the command line.

My experience is that, using egcs/gcc and gld, a binary winds up with an
rpath set to the usual ld paths _plus_ the cross-compiler lib paths and all
relative -L paths on the gcc command line.  That's rather broken. 

I have a quick patch to "fix" these vs. binutils 2.8.1--the -L options are
_always_ searched for shared libraries (though it kinda makes -rpath-link
moot), and the rpath defaults to empty and is not built from -L options (it
is built only from an explicit set of -rpath options).  This "fixed" 
behavior appears to be the default for ELF platforms, but I'm not currently
positive. 

=====
===== Todd Vierling (Personal tv@pobox.com) =====
== "There's a myth that there is a scarcity of justice to go around, so
== that if we extend justice to 'those people,' it will somehow erode the
== quality of justice everyone else receives."  -- Maria Price

Re: rpath semantics in binutils?

[Ian Lance Taylor]

   Date: Thu, 29 Jan 1998 20:19:53 -0500 (EST)
   From: Todd Vierling <tv@pobox.com>

   Not that this is directly related to egcs, but upon building and using a
   cross compiler for SunOS 4.1.x SPARC, I found that GNU ld does the following
   (rather odd, in my opinion) things with -L and -rpath for SunOS (sunos.em). 

GNU ld discussion is better held on bug-gnu-utils, or bfd@cygnus.com.

   - If -rpath is specified on the command line, no directories specified by
     -L are searched for shared libraries.  (They then have to be specified
     with -rpath-link.)

To clarify: shared libraries which are required by other shared
libraries are only searched for on the -rpath-link directories and the
-rpath directories.  If you specify -rpath, they are not searched for
on the -L directories.  Shared libraries which are explicitly
specified on the command line are searched for using the -L path as
usual.

This behaviour is intended to make the linker simulate the dynamic
linker when searching for a shared library which was not explicitly
specified on the command line.  If the linker can not find the shared
library using the above rules, the dynamic linker will also not be
able to find the library.  Thus, the linker attempts to anticipate the
error you will get from the dynamic linker, and to give you the error
at link time rather than at run time.

I believe this behaviour is essentially identical to that of the ELF
targeted GNU linker.

   - The binary's rpath (list of runtime shared library search paths) is built
     from internal library paths (unless -nostdlib) and all -L options.  This
     is more than bogus for a cross-compiler, and IMHO, rpath should only be
     created if one is explicitly specified on the command line.

Creating the rpath from the -L options is what the native SunOS linker
does.  I agree that it is problematical, but changing it would break
some tools intended to be built with the SunOS linker.  The -rpath
option is a GNU extension to permit additional control over the
runtime search path.

I can see how this is less useful for a cross linker.  However, some
form of mapping -L to rpath would seem appropriate even for a cross
linker, in order to make it possible to build some SunOS programs with
a SunOS cross linker.  I'm not sure what the best solution is here.

   I have a quick patch to "fix" these vs. binutils 2.8.1--the -L options are
   _always_ searched for shared libraries (though it kinda makes -rpath-link
   moot), and the rpath defaults to empty and is not built from -L options (it
   is built only from an explicit set of -rpath options).  This "fixed" 
   behavior appears to be the default for ELF platforms, but I'm not currently
   positive. 

As noted above, not searching -L for a shared library referenced by
another shared library is how the ELF linker works.  ELF linkers do
not build rpath from the -L options, but changing that breaks
compatibility with the native SunOS linker.  So I do not think this
patch is appropriate.

Ian