-
Bug
-
Resolution: Fixed
-
P4
-
23
-
b13
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8327699 | 22.0.2 | Erik Joelsson | P4 | Resolved | Fixed | b01 |
JDK-8327634 | 21.0.4-oracle | Erik Joelsson | P4 | Resolved | Fixed | b01 |
JDK-8327956 | 21.0.4 | Andrew Lu | P4 | Resolved | Fixed | b01 |
JDK-8327635 | 17.0.12-oracle | Erik Joelsson | P4 | Resolved | Fixed | b01 |
JDK-8327961 | 17.0.12 | Andrew Lu | P4 | Resolved | Fixed | b01 |
JDK-8327632 | 11.0.24-oracle | Erik Joelsson | P4 | Resolved | Fixed | b01 |
JDK-8327960 | 11.0.24 | Andrew Lu | P4 | Resolved | Fixed | b01 |
JDK-8327633 | 8u421 | Erik Joelsson | P4 | Resolved | Fixed | b01 |
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 internal dependencies between 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.
An alternate solution to this would be to better name any internal JDK library with a namespace prefix to make clashes with other external libraries less likely.
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".
- backported by
-
JDK-8327632 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
-
JDK-8327633 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
-
JDK-8327634 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
-
JDK-8327635 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
-
JDK-8327699 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
-
JDK-8327956 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
-
JDK-8327960 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
-
JDK-8327961 Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
- Resolved
- links to
-
Commit openjdk/jdk11u-dev/069fbd77
-
Commit openjdk/jdk17u-dev/0606e5ac
-
Commit openjdk/jdk21u-dev/7f5afa18
-
Commit openjdk/jdk22u/f510fe81
-
Commit openjdk/jdk/721bfee5
-
Review openjdk/jdk11u-dev/2592
-
Review openjdk/jdk17u-dev/2282
-
Review openjdk/jdk21u-dev/345
-
Review openjdk/jdk22u/89
-
Review openjdk/jdk/18050