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

[David Holmes]

Looks neat. :)

Thanks,
David

On 20/04/2018 4:59 PM, Siebenborn, Axel wrote:
>>
>> 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
> 
> Yes, seems to be little known, as nobody uses it. ��
> However, it works.
> New webrev:
> 
> http://cr.openjdk.java.net/~asiebenborn/require_musl/webrev_at_comment/
> 
> Cheers,
> Axel
> 
>>
>>>
>>> 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
>>>>>>
>>>>