Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]
On Tue, 5 Mar 2024 14:19:14 GMT, Erik Joelsson wrote: > Does the release note also looks ok? Yes. > Is there any process to formally review release notes? No. Typically just add a comment to the RN sub-task indicating it is okay. My comment, that I had made some minor changes was meant as an indicator of that. - PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1980229076
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]
On Mon, 4 Mar 2024 23:44:14 GMT, Erik Joelsson 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: > > bug ref Yes, the release note looks good. Is there any process to formally review release notes? - PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-197625
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]
On Tue, 5 Mar 2024 07:16:10 GMT, David Holmes wrote: > Thanks for the further explanation and adding the comment. > > LGTM. Thanks! Does the release note also looks ok? I understand it needs to be reviewed together with the PR. - PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1978879864
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]
On Mon, 4 Mar 2024 23:44:14 GMT, Erik Joelsson 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: > > bug ref Thanks for the further explanation and adding the comment. LGTM. - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18050#pullrequestreview-1916027301
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]
> 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: bug ref - Changes: - all: https://git.openjdk.org/jdk/pull/18050/files - new: https://git.openjdk.org/jdk/pull/18050/files/faafef8a..8639eee5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18050=03 - incr: https://webrevs.openjdk.org/?repo=jdk=18050=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]
On Mon, 4 Mar 2024 14:53:21 GMT, Magnus Ihse Bursie wrote: >> 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. > > I agree. A short description and a reference to this bug number would be nice. Added comment. - PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1511291650
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]
On Sun, 3 Mar 2024 22:12:19 GMT, David Holmes wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use @requires in test > > 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. I agree. A short description and a reference to this bug number would be nice. - PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1511290973
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v3]
On Mon, 4 Mar 2024 14:57:44 GMT, Erik Joelsson 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: > > Add comment Marked as reviewed by ihse (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18050#pullrequestreview-1914533756
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v3]
> 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: Add comment - Changes: - all: https://git.openjdk.org/jdk/pull/18050/files - new: https://git.openjdk.org/jdk/pull/18050/files/592281f2..faafef8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18050=02 - incr: https://webrevs.openjdk.org/?repo=jdk=18050=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 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
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]
On Sun, 3 Mar 2024 22:09:51 GMT, David Holmes wrote: > 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`. Your point here is the reason it took me this long to come to the realization that my proposal here is correct for a product like the JDK. I have been dealing with these rpaths several time over the years and have been confused over the significance of the two kinds, but figured that since RUNPATH is the new variant and the general move is towards that, we should just stick to that too. However, as I allude to in the bug description, we aren't really fitting the usecases the default is aiming to solve. If you are building a single library for distribution, or to install in your local Linux distribution, then letting the user have the option to customize the dynamic loader with LD_LIBRARY_PATH by default seems reasonable. I can see why Linux distributions prefer having LD_LIBRARY_PATH available to override rpaths as well. They want to promote applications that are well integrated with the system and using the system versions of all dependency libraries instead of bundling their own competing versions. However, what we are building is more of a self contained application. When users jlink an application, it becomes even more obvious. RPATH allows us to completely self contain the dependencies between our _internal_ native libraries. Any external dependency that the JDK has (glibc etc) we still link to from the system the same way as before. Looking for discussions about RPATH and RUNPATH online, this is basically the conclusion I find. A better solution would perhaps have been to name our internal libraries better, using a namespace that would make name clashes with other external libraries less likely (e.g. libjavanet.so instead of libnet.so). If we had done that, then this issue would probably not have been worth raising. - PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1976750074
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]
On Fri, 1 Mar 2024 13:58:08 GMT, Erik Joelsson 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
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]
On Fri, 1 Mar 2024 13:58:08 GMT, Erik Joelsson 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 Marked as reviewed by ihse (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18050#pullrequestreview-1911804757
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]
> 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 - Changes: - all: https://git.openjdk.org/jdk/pull/18050/files - new: https://git.openjdk.org/jdk/pull/18050/files/749a95f9..592281f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18050=01 - incr: https://webrevs.openjdk.org/?repo=jdk=18050=00-01 Stats: 9 lines in 1 file changed: 2 ins; 3 del; 4 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
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]
On Fri, 1 Mar 2024 06:30:14 GMT, David Holmes wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use @requires in test > > test/jdk/tools/launcher/RunpathTest.java line 27: > >> 25: * @test >> 26: * @bug 7190813 8022719 >> 27: * @summary Check for extended RPATHs on Linux > > Pre-existing but really the restriction to Linux should be via `@requires` > not a runtime test. Fixed - PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1509047068
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson 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". test/jdk/tools/launcher/RunpathTest.java line 27: > 25: * @test > 26: * @bug 7190813 8022719 > 27: * @summary Check for extended RPATHs on Linux Pre-existing but really the restriction to Linux should be via `@requires` not a runtime test. - PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1508535229
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
On Thu, 29 Feb 2024 06:34:42 GMT, David Holmes wrote: > I can imagine it could be used to allow "hot patching" of the installed > JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest > at least adding a Release Note. Added release note. - PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1971267771
Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote: > There is no supported usecase that I can think of for injecting other > versions of such libraries in a JDK distribution. I can imagine it could be used to allow "hot patching" of the installed JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest at least adding a Release Note. - PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1970497315
RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries
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=18050=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
