RFR: Force setting LD_LIBRARY_PATH in launcher

[Poonam Parhar]

What is the cost and implications of always setting LD_LIBRARY_PATH on all linux flavors rather than adding all these conditional for different linux distributions and C libraries?

And rather than checking for the musl library (and having these variables passed around), can't we check if we are running on Alpine Linux, similar to the check we perform for AIX:

244#ifdef AIX
245    /* We always have to set the LIBPATH on AIX because ld doesn't support $ORIGIN. */
246    return JNI_TRUE;
247#endif

Why can't we have something like:

#ifdef ALPINE
	/* We always have to set the LIBPATH on ALPINE*/
	return JNI_TRUE;
#endif

Thanks,
Poonam

> -----Original Message-----
> From: Kumar Srinivasan
> Sent: Wednesday, April 12, 2017 7:21 AM
> To: David Holmes; Mikael Vidstedt
> Cc: portola-dev at openjdk.java.net
> Subject: Re: RFR: Force setting LD_LIBRARY_PATH in launcher
> 
> 
> I don't like all the conditionals in that launcher code, and I don't
> have a good answer to solve this either. If we have to, go for it, but
> maybe group all those platforms which need LLP under one conditional ?
> and make that code more readable.
> 
> Kumar
> 
> > On 12/04/2017 3:23 PM, Mikael Vidstedt wrote:
> >>
> >>> 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/webr
> >>>> ev.00/webrev/
> >>>>
> >>>>
> http://cr.openjdk.java.net/~mikael/webrevs/portola/launcherfix/webr
> >>>> ev.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 :)
> >
> > Until we support some other non-glibc library it seems like a pretty
> > safe bet!
> >
> > But as discussed on IM the VM knowing it is on musl doesn't help. The
> > problem is that the launcher loaded a specific libjvm by path
> (client,
> > server, minimal) and libjava has a dependency on libjvm but with no
> > location info. libjvm is not in any of the ld search locations, hence
> > the musl loader won't find it, as it doesn't consider the already
> > loaded libjvm to be a candidate.
> >
> > Short term solution - hack LD_LIBRARY_PATH in launcher.
> >
> > BTW is what we are seeing with musl the same as what happens on AIX:
> >
> > /* We always have to set the LIBPATH on AIX because ld doesn't
> support
> > $ORIGIN. */
> >
> > ??
> >
> > Long term solution ... use a single unified DSO for java and the jvm
> > (and jli?) and dispense with JREs that contain multiple VMs.
> >
> > Cheers,
> > David
> >
> >> Cheers,
> >> Mikael
> >>
>