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

Siebenborn, Axel axel.siebenborn at sap.com
Thu Apr 12 10:12:37 UTC 2018


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

> 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