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

[David Holmes]

On 20/04/2018 8:10 AM, David Holmes wrote:
> On 20/04/2018 1:51 AM, Siebenborn, Axel wrote:
>>> -----Original Message-----
>>> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com]
>>>
>>> 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?
>>
>> I wasn't sure where to add the add the comment. So, I just looked at 
>> other tests
>> and the only comments to an '@require' I found, were made this way.
> 
> At some point jtreg started supporting an @comment tag, but it seems to 
> be little known. I only stumbled on it by accident recently. It's not 
> listed in the tag-spec:
> 
> http://openjdk.java.net/jtreg/tag-spec.html

Added 6 months ago:

http://hg.openjdk.java.net/code-tools/jtreg/rev/be78b85a101e

David

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