RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

[Erik Joelsson]

On Sun, 3 Mar 2024 22:09:51 GMT, David Holmes <dholmes at openjdk.org> 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