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

[David Holmes]

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.

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