RFR: Force setting LD_LIBRARY_PATH in launcher

[Magnus Ihse Bursie]

On 2017-04-12 04:35, Mikael Vidstedt wrote:
> This one is a big tricky:
>
> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/webrev/
> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webrev.00/jdk/webrev/
>
> The end goal is to get the launcher (java_md_solinux.c) to add the path to libjvm.so to LD_LIBRARY_PATH, but to only do so if running/building for musl. Here’s the comment I added to java_md_solinux.c, which hopefully explains why this is needed:
>
>        /*
>         * The musl library loader requires LD_LIBRARY_PATH to be set in
>         * order to correctly resolve the dependency libjava.so has on libjvm.so.
>         *
>         * Specifically, it differs from glibc in the sense that even if
>         * libjvm.so has already been loaded it will not be considered a
>         * candidate for resolving the dependency unless the *full* path
>         * of the already loaded library matches the dependency being loaded.
>         *
>         * libjvm.so is being loaded by the launcher using a long path to
>         * dlopen, not just the basename of the library. Typically this
>         * is something like "../lib/server/libjvm.so". However, if/when
>         * libjvm.so later tries to dlopen libjava.so (which it does in
>         * order to get access to a few functions implemented in
>         * libjava.so) the musl loader will, as part of loading
>         * dependent libraries, try to load libjvm.so using only its
>         * basename "libjvm.so". Since this does not match the longer
>         * path path it was first loaded with, the already loaded
>         * library is not considered a candidate, and the loader will
>         * instead look for libjvm.so elsewhere. If it's not in
>         * LD_LIBRARY_PATH the dependency load will fail, and libjava.so
>         * will therefore fail as well.
>         */
> Since there is no way to know at runtime that musl is being used, and there is no “system” compile time define to base the decision on, this change adds support to the JDK build system to set up a OPENJDK_{BUILD,TARGET}_CLIB variables based on the autoconf tuple, passing in the value to java_md_solinux.c as a compiler define -DCLIB=“…”, using that define to check for musl in RequiresSetenv, and returning true to force the setting of LD_LIBRARY_PATH if there’s a match.
>
> Definitely could use some feedback on this one.
Finally, something that's not just nice cleanups that I can shoot down! ;-)

This issue touches two messy areas:

1) The LD_LIBRARY_PATH.

There's a lot of hand-waving and dark ritual magic around the loading of 
libraries in our code. The entire RequiresSetenv seems ... like, eh, the 
world would be a better place if it didn't exist. I wonder if part of 
the reason it exists and looks so problematic is due to that we compile 
our native libraries with incorrect flags. Wouldn't surprise me.

2) Describing platforms with more detail than just os-cpu.

You are in effect turning OS_CPU into OS+CLIB_CPU, but it feels a bit 
too much add-on. If we don't have a specified CLIB, you leave it empty. 
Perhaps having "platform" or "native" or "default" in other cases? I 
don't like empty values.

Another approach, don't know if it's good or bad, is to reuse the 
"OPENJDK_[BUILD/TARGET]_OS_ENV". Originally used to distinguish cygwin 
from msys on Windows, it is now also used (in the BSD port only, not 
integrated into mainline) to distinguish between free/net/open BSD. So 
it's more of a "sub-OS specification". (Yeah, the name ENV is perhaps 
not ideal). In a way, I think the clib distinction (glibc vs musl) is 
sort-of a similar question. That is, in some circumstances you must be 
able to differ between "windows" (in general) from "windows.cygwin" or 
"windows.msys", or "bsd" (in general) from "bsd.freebsd" or whatever. 
And sometimes, you need to differ between "linux" (in general) from 
"linux.glibc" or "linux.musl".

/Magnus

>
> Cheers,
> Mikael
>