RFR(XS) [TESTBUG] hotspot/jtreg/gtest/GTestWrapper.java fails on AIX and MUSL

[Siebenborn, Axel]

Hi,
> -----Original Message-----
> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com]
> Sent: Freitag, 20. April 2018 20:05
> To: Siebenborn, Axel <axel.siebenborn at sap.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(XS) [TESTBUG] hotspot/jtreg/gtest/GTestWrapper.java fails
> on AIX and MUSL
> 
> 
> I was almost certain that I had already fixed this. And it turned out I had.
> Locally, and then forgotten to actually get the fix pushed :)
> 
> This is almost exactly the same code I ended up with (although I only did it for
> LD_LIBRARY_PATH).
> 
> Looks good. Perhaps a short comment in the code explaining what’s going
> on?
> 
> Also, small nit: the spaces around the “pb” argument on the last line :)

I added a short comment and removed the superfluous spaces.

New webrev:
http://cr.openjdk.java.net/~asiebenborn/jtreg_GTestWrapper/webrev_01/

Thanks,
Axel

> 
> Cheers,
> Mikael
> 
> 
> > On Apr 20, 2018, at 4:06 AM, Siebenborn, Axel
> <axel.siebenborn at sap.com> wrote:
> >
> > Hi,
> >
> > Webrev:
> http://cr.openjdk.java.net/~asiebenborn/jtreg_GTestWrapper/webrev/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8195002
> >
> > The test hotspot/jtreg/gtest/GTestWrapper.java fails on AIX, alpine/musl
> and probably in all cases RequiresSetenv() in
> java.base/unix/native/libjli/java_md_solinux.c returns "true".
> > The problem is, that the java launcher sets the library path
> (LD_LIBRARY_PATH or LIB_PATH). The test starts an executable, that is
> dynamically linked against a special gtests libjvm. Due to the inherited library
> path, the wrong libjvm is linked.
> > The fix is to use ProcessBuilder and set the env variable for
> LD_LIBRARY_PATH or LIBPATH to the special gtest libjvm.
> >
> > Cheers,
> > Axel