Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8326891

Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries

    XMLWordPrintable

Details

    • b13
    • linux

    Backports

      Description

        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 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".

        Attachments

          Issue Links

            Activity

              People

                erikj Erik Joelsson
                erikj Erik Joelsson
                Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: