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

[Mikael Vidstedt]

Thanks for adding the comment. I’m curious, what was the reason for adding it as a separate block? Does it mess up for jtreg to have it next to the @requires itself in some way?

Cheers,
Mikael

> On Apr 19, 2018, at 2:05 AM, Siebenborn, Axel <axel.siebenborn at sap.com> wrote:
> 
> Hi,
> I added a comment and updated the webrev:
> 
> http://cr.openjdk.java.net/~asiebenborn/require_musl/webrev_run_time
> 
> Cheers,
> Axel
> 
> 
> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com] 
> Sent: Dienstag, 17. April 2018 19:25
> To: Siebenborn, Axel <axel.siebenborn at sap.com>
> Cc: David Holmes <david.holmes at oracle.com>; portola-dev at openjdk.java.net
> Subject: Re: jtreg test test java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
> 
> 
> Looks good. Maybe a short comment about why the test is not run on musl?
> 
> Cheers,
> Mikael
> 
> On Apr 12, 2018, at 7:33 AM, Siebenborn, Axel <mailto:axel.siebenborn at sap.com> wrote:
> 
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 12. April 2018 14:17
> To: Siebenborn, Axel <mailto:axel.siebenborn at sap.com>; portola-
> mailto:dev at openjdk.java.net
> Subject: Re: jtreg test test
> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java
> 
> 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 <mailto:david.holmes at oracle.com>; portola-
> mailto: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 :)
> 
> I added a new webrev using ldd --version:
> 
> http://cr.openjdk.java.net/~asiebenborn/require_musl/webrev_run_time/
> 
> Cheers,
> Axel
> 
> 
> 
> 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 <mailto:axel.siebenborn at sap.com>; portola-
> mailto: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
>