RFR: Add musl information to bundle names and -Xinternalversion

[David Holmes]

On 27/04/2017 10:35 AM, David Holmes wrote:
> On 27/04/2017 8:39 AM, Mikael Vidstedt wrote:
>>
>> Actually not, but I can see how these changes are confusing enough to
>> make it seem like that’s the case. The key here is the difference
>> between OPENJDK_TARGET_CLIB and OPENJDK_TARGET_CLIB_BUNDLE. The former
>> is what is baked into the release file, and it always has a value
>> (either “musl”, “gnu”, or “default”). The latter is what is used to
>> form the name of the bundle files (the .tar.gz ones), and that suffix
>> string is either “-musl”, or empty.
>>
>> Does that make sense?
>
> I don't see where OPENJDK_TARGET_CLIB gets any value set ??

Never mind - earlier webrev. Sorry.

David

> David
>
>
>
>> Cheers,
>> Mikael
>>
>>> On Apr 25, 2017, at 4:14 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>
>>> Hi Mikael,
>>>
>>> One nit. In make/ReleaseFile.gmk you unconditionally add an entry for
>>> "CLIB" but unless on musl that will be an empty string. Seems to me
>>> either we always have a defined value for CLIB or else we only
>>> conditionally add it to the release info file.
>>>
>>> Cheers,
>>> David
>>>
>>> On 19/04/2017 6:56 AM, Mikael Vidstedt wrote:
>>>>
>>>> I linked to the wrong webrevs, sorry about that. Please have a look
>>>> at these ones instead (which reflect the changes I actually pushed):
>>>>
>>>> top:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/
>>>> <http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/webrev/>
>>>>
>>>> hotspot:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/
>>>> <http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.02/hotspot/webrev/>
>>>>
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>>> On Apr 18, 2017, at 3:18 AM, Erik Joelsson
>>>>> <erik.joelsson at oracle.com> wrote:
>>>>>
>>>>> It looks to me like your code in platform.m4 will indeed change the
>>>>> platform name on gnu linux (and all other platforms) to add a
>>>>> trailing dash '-' for the bundle platform.
>>>>>
>>>>> I also fail to see where the dash before musl is added in the
>>>>> version string?
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2017-04-13 18:02, Mikael Vidstedt wrote:
>>>>>> With the introduction of musl <os>-<arch> (and specifically
>>>>>> linux-amd64) is no longer uniquely identifying the JDK platform
>>>>>> and binaries.
>>>>>>
>>>>>> This change adds “musl” in a couple of places:
>>>>>>
>>>>>> top:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/webrev/
>>>>>>
>>>>>> hotspot:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/version/webrev.01/hotspot/webrev/
>>>>>>
>>>>>>
>>>>>>
>>>>>> The two places are:
>>>>>>
>>>>>> 1. The bundle file names
>>>>>>
>>>>>> A typical linux-amd64 bundle today looks something like this:
>>>>>>
>>>>>> jdk-10-internal+0_linux-x64_bin.tar.gz
>>>>>>
>>>>>> At least for now, the “normal”/gnu bundle file names will *not* be
>>>>>> changed - only the new “musl” ones will get the additional “-musl”
>>>>>> component:
>>>>>>
>>>>>> jdk-10-internal+0_linux-x64-musl_bin.tar.gz
>>>>>>
>>>>>>
>>>>>> 2. The -Xinternalversion version string
>>>>>>
>>>>>> Much like with the bundle names, the current string looks
>>>>>> something like:
>>>>>>
>>>>>> Java HotSpot(TM) 64-Bit Server VM
>>>>>> (10-internal+0-2017-04-10-172118.mikael.portola) for linux-amd64
>>>>>> JRE (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr
>>>>>> 13 2017 08:48:18 by "mikael" with gcc 4.9.2
>>>>>>
>>>>>> This patch (only) adds “-musl” for the musl version of the JVM,
>>>>>> and leaves non-musl platforms unchanged. With musl the
>>>>>> -Xinternalversion version string looks something like:
>>>>>>
>>>>>> Java HotSpot(TM) 64-Bit Server VM
>>>>>> (10-internal+0-2017-04-10-172118.mikael.portola) for
>>>>>> linux-amd64-musl JRE
>>>>>> (10-internal+0-2017-04-10-172118.mikael.portola), built on Apr 13
>>>>>> 2017 08:34:03 by "mikael" with gcc 4.9.2
>>>>>>
>>>>>> but without the bold highlighting ;)
>>>>>>
>>>>>>
>>>>>> As I mentioned in the thread [1] for the confstr/libc/libpthread
>>>>>> patch I will take another round through the code after I have this
>>>>>> in place and make sure everything is handled in a consistent manner.
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/portola-dev/2017-April/000021.html
>>>>>>
>>>>>>
>>>>>
>>>>
>>