Executables and dynamic libraries on Linux can encode a search path that the 
dynamic linker will use when looking up library dependencies, generally 
referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to 
set search paths relative to the location of the binary itself. Typically 
executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find 
libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to 
find each other.

There are two different types of such rpaths, RPATH and RUNPATH. The former is 
the earlier incantation but RUNPATH has been around since about 2003 and has 
been default in prominent Linux distros for a long time, and now also seems to 
be default in the linker directly from binutils. The toolchain used by Oracle 
defaulted to RPATH until at least JDK 11, but since then with some toolchain 
upgrade, the default was flipped to RUNPATH.

The main (relevant in this case) difference between the two is that RPATH is 
considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is 
only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux 
distribution, letting users, or the system, control and override builtin rpaths 
with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the 
JDK, there really is no usecase for having an externally configured 
LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding 
each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is 
a library in that path with the same name as a JDK library (e.g. libnet.so or 
some other generically named library) that external library will be loaded 
instead of the JDK internal library and that is basically guaranteed to break 
the JDK. There is no supported usecase that I can think of for injecting other 
versions of such libraries in a JDK distribution.

I propose that we explicitly configure the JDK build to set RPATH instead of 
RUNPATH for Linux binaries. This is done with the linker flag 
"--disable-new-dtags".

-------------

Commit messages:
 - JDK-8326891

Changes: https://git.openjdk.org/jdk/pull/18050/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18050&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326891
  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18050/head:pull/18050

PR: https://git.openjdk.org/jdk/pull/18050

Reply via email to