On Fri, 1 Mar 2024 13:58:08 GMT, Erik Joelsson <er...@openjdk.org> wrote:
>> 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". > > Erik Joelsson has updated the pull request incrementally with one additional > commit since the last revision: > > Use @requires in test I find it somewhat odd that we seem to be add odds with the general programming community when it comes to this behaviour. Giving precedence to `LD_LIBRARY_PATH` is the new behaviour, enabled via `--enable-new-dtags`; and at some point this was made the default behaviour so it must be considered generally desirable. But we have now decided we do not want this behaviour so we have to explicitly disable it via `--disable-new-dtags`. make/autoconf/flags-cflags.m4 line 40: > 38: # Default works for linux, might work on other platforms as well. > 39: SHARED_LIBRARY_FLAGS='-shared' > 40: SET_EXECUTABLE_ORIGIN='-Wl,-rpath,\$$ORIGIN[$]1 > -Wl,--disable-new-dtags' The reason we use `--disable-new-dtags` needs to be documented somewhere. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1975375484 PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1510411289
