Re: binutils 2.28 breaking libtool for test programs when -no-install is used

[Russ Allbery]

Thomas Jahns <address@hidden> writes:
> On 06/01/2017 11:09 AM, Vincent Lefevre wrote:
>> On 2017-06-01 09:56:29 +0200, Thomas Jahns wrote:

>>> GCC doesn't generate binaries or shared libraries, ld does. Passing

>>> -Wl,-rpath,/path/to/dependency/lib

>> But this is not automatic. When typing

>>   $CC program.c -o program -lmpfr -lgmp

>> (where $CC can be gcc, tcc or icc, for instance), things should just
>> work, i.e. the correct options should be passed to ld *by default*.

> That would be nice, on AIX directories passed with -L are also added to
> the run-time library search path.

This approach has serious drawbacks, though.  Often, binaries are built
against libraries in temporary staging areas (this is particularly common
when installing into AFS file systems, but it comes up in other cases as
well), and AIX's behavior, unless managed very carefully, can create
serious security holes by looking in those directories for libraries by
default.  This is the reason for the libtool relink after install step,
which isn't necessary on Linux but is vital on platforms that have
AIX-like behavior (and has various issues of its own).

There is no solution to this problem that works for every common binary
building scenario.  Both the approach of only searching system library
paths by default and the approach of embedding paths to the linked
libraries by default has serious advantages in some situations and serious
drawbacks in other situations.

For better or worse, Linux has standardized thoroughly on only searching
system library paths regardless of where the libraries were when linked
unless explicitly configured otherwise with -R, -rpath, or LD_RUN_PATH,
and now lots of other tools expect and manage that behavior.  Changing it
would break things, rather horribly.

(This is somewhat afield of the original issue, though, which was a change
from RPATH to RUNPATH, and does sound rather surprising.)

-- 
Russ Allbery (address@hidden)              <http://www.eyrie.org/~eagle/>