RFR: Force setting LD_LIBRARY_PATH in launcher

Mikael Vidstedt mikael.vidstedt at oracle.com
Wed Apr 12 05:23:37 UTC 2017

> On Apr 11, 2017, at 8:55 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 12/04/2017 12:35 PM, 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.
> I had not realized that the dynamic loader was part of libc. I had assumed it was part of the OS proper.
>>       *
>>       * 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.
> But we can infer we are using musl if we don't get any glibc version information.

We could. I’m not a fan of having !glibc imply musl though. Like, at all. Not saying you can’t change my mind, but you’ll have to work on it :)


More information about the portola-dev mailing list