RFR: Force setting LD_LIBRARY_PATH in launcher

[Kumar Srinivasan]

On 4/12/2017 3:25 AM, Magnus Ihse Bursie wrote:
>
> 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, 

RequiresSetenv was added to solve rt linking issues, take for instance 
ant running jdk6 (which
sets LD_LIBRARY_PATH to its own versions of libjvm.so ) and execs jdk7, 
jdk8, jdk9 ? Want to
take a guess what happens in this case ? ;) So this (RequiresSetenv) was 
intended to be a
temporary fix, ie. until users move to newer JDKs without the LLP 
requirement, but with this
project and AIX purging LLP might get even more distant.

Kumar



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