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

[Langer, Christoph]

Hi Axel,

looks good. Don't forget to update the current year in the copyright header.

Best regards
Christoph

> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> bounces at openjdk.java.net] On Behalf Of Siebenborn, Axel
> Sent: Montag, 23. April 2018 11:02
> To: Mikael Vidstedt <mikael.vidstedt at oracle.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: [CAUTION] RE: RFR(XS) [TESTBUG]
> hotspot/jtreg/gtest/GTestWrapper.java fails on AIX and MUSL
> 
> 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