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

[Siebenborn, Axel]

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

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