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

[David Holmes]

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 :)

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
>>>>>>>>