RFC: 8229469 JEP 386: Alpine Linux/x64 Port

[Aleksei Voitylov]

Alan,

in this case I'm leaning towards a new class jdk.test.lib.LibcHelper
with a native implementation which calls (*env)->NewStringUTF(env,
libc), which will be used by the tests which require it. Otherwise we'd
have to specify nativepath for all tests which use
jdk.test.lib.Platform. What do you think?

-Aleksei

On 04/09/2020 12:08, Alan Bateman wrote:
> On 04/09/2020 10:00, Alan Bateman wrote:
>> On 04/09/2020 08:55, Aleksei Voitylov wrote:
>>> :
>>> Tests tools/launcher/Test7029048.java and
>>> tools/launcher/ExecutionEnvironment.java need to change behavior on
>>> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we
>>> first considered was to detect the libc of the OS with ldd in the test
>>> and avoid WhiteBox dependency. This approach has a significant
>>> drawback:
>>> some distributions bundle glibc and OpenJDK and launch it on a
>>> musl-based Linux OS, so we really need to detect the libc the JDK was
>>> compiled for, not the default libc present in the OS. To avoid such
>>> problems all together it was decided to detect the libc flavor the JDK
>>> was compiled for through WhiteBox.
>>>
>> I really dislike the changes to the launcher tests and I don't think
>> the WB API is the right place for this. I think we need to find
>> something cleaner and maybe expose it as a method on
>> jdk.test.lib.Platform.
>>
> or alternatively, a new class in jdk.test.lib that gives provide
> methods to introspect the runtime, whatever is simplest and doesn't
> depend on the WB API as it's independent of HotSpot.
>
> -Alan