jtreg test test java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java

[Mikael Vidstedt]

Looks good. Maybe a short comment about why the test is not run on musl?

Cheers,
Mikael

> On Apr 12, 2018, at 7:33 AM, Siebenborn, Axel <axel.siebenborn at sap.com> wrote:
> 
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>]
>> Sent: Donnerstag, 12. April 2018 14:17
>> To: Siebenborn, Axel <axel.siebenborn at sap.com <mailto:axel.siebenborn at sap.com>>; portola-
>> dev at openjdk.java.net <mailto:dev at openjdk.java.net>
>> Subject: Re: jtreg test test
>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
>> 
>> On 12/04/2018 9:34 PM, Siebenborn, Axel wrote:
>>>> -----Original Message-----
>>>> From: portola-dev [mailto:portola-dev-bounces at openjdk.java.net] On
>>>> Behalf Of Siebenborn, Axel
>>>> Sent: Donnerstag, 12. April 2018 13:30
>>>> To: David Holmes <david.holmes at oracle.com>; portola-
>>>> dev at openjdk.java.net
>>>> Subject: [CAUTION] RE: jtreg test test
>>>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Donnerstag, 12. April 2018 12:54
>>>>> To: Siebenborn, Axel <axel.siebenborn at sap.com>; portola-
>>>>> dev at openjdk.java.net
>>>>> Subject: Re: jtreg test test
>>>>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
>>>>> 
>>>>> On 12/04/2018 8:12 PM, Siebenborn, Axel wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Donnerstag, 12. April 2018 11:29
>>>>>>> To: Siebenborn, Axel <axel.siebenborn at sap.com>; portola-
>>>>>>> dev at openjdk.java.net
>>>>>>> Subject: Re: jtreg test test
>>>>>>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
>>>>>>> 
>>>>>>> On 12/04/2018 7:03 PM, Siebenborn, Axel wrote:
>>>>>>>> Hi,
>>>>>>>> As there is no whitebox function to identify musl, I added one:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~asiebenborn/require_musl/webrev/
>>>>>>>> 
>>>>>>>> What do you think?
>>>>>>> 
>>>>>>> That works, but is there a musl equivalent of gnu_get_libc_version? A
>>>>>>> simple native runtime check would be better than all the build time
>>>>>>> machinations if possible.
>>>>>>> 
>>>>>> I suppose there is nothing like that, on purpose.
>>>>>> For the same reasons, there is no __MUSL__ macro equivalent to
>>>>> __GLIBC__:
>>>>>> https://wiki.musl-
>>>>> libc.org/faq.html#Q:_why_is_there_no_MUSL_macro_.3F
>>>>> 
>>>>> Typical unrealistic idealistic response. :(
>>>>> 
>>>>> I suppose if you can't dllookup gnu_get_libc_version then you could
>>>>> assume it must be musl.
>>>>> 
>>>> Probably, that would work, but maybe a bit to hacky ��.
>>>> 
>>>>> In the build solution:
>>>>> 
>>>>>   ifeq ($(HOTSPOT_TARGET_LIBC),musl)
>>>>> 
>>>>> what sets this to musl? Is it a manually supplied configure arg?
>>>>> 
>>>> 
>>>> No need for a configure arg. It is determined by autoconf:
>>>> /make/autoconf.platform.m4
>>> ... and config.guess parses the output of
>>> ldd --version
>> 
>> Well there's another option then :)
> 
> I added a new webrev using ldd --version:
> 
> http://cr.openjdk.java.net/~asiebenborn/require_musl/webrev_run_time/ <http://cr.openjdk.java.net/~asiebenborn/require_musl/webrev_run_time/>
> 
> Cheers,
> Axel
> 
>> 
>> Cheers,
>> David
>> 
>>> 
>>>> 
>>>>> David
>>>>> 
>>>>>>> David
>>>>>>> 
>>>>>>>> Axel
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>> Sent: Dienstag, 10. April 2018 13:44
>>>>>>>>> To: Siebenborn, Axel <axel.siebenborn at sap.com>; portola-
>>>>>>>>> dev at openjdk.java.net
>>>>>>>>> Subject: Re: jtreg test test
>>>>>>>>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
>>>>>>>>> 
>>>>>>>>> On 10/04/2018 9:24 PM, Siebenborn, Axel wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> I had a look on the test
>>>>>>>>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
>>>>>>>>>> 
>>>>>>>>>> This test fails, because a  loaded native library is not removed by
>> the
>>>>> GC.
>>>>>>>>>> The native library should be unloaded by dlclose, but this is a noop
>> in
>>>>>>> musl
>>>>>>>>>> (https://wiki.musl-libc.org/functional-differences-from-
>> glibc.html)
>>>>>>>>>> 
>>>>>>>>>> Any idea, how this should be handled?
>>>>>>>>>> Should this test be skipped for musl?
>>>>>>>>> 
>>>>>>>>> I would say there is no choice :( Is there a whitebox function to
>>>>>>>>> identify musl so you can use @requires ?
>>>>>>>>> 
>>>>>>>>> I don't buy their argument as to why dlclose is a no-op. Yes it's
>>>>>>>>> "safer" in the same sense that standing still is safer than moving -
>> but
>>>>>>>>> nowhere near as useful.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> David
>>>>>>>>>> Regards,
>>>>>>>>>> Axel