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

David Holmes david.holmes at oracle.com
Thu Apr 12 10:54:13 UTC 2018


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.

In the build solution:

  ifeq ($(HOTSPOT_TARGET_LIBC),musl)

what sets this to musl? Is it a manually supplied configure arg?

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


More information about the portola-dev mailing list