[8u] RFR: 8255003: Build failures on Solaris (was Re: Build failures on illumos (Solaris))

[Andrew Brygin]

Hello Andrew,

On 21/10/2020 19:09, Andrew Hughes wrote:
> On 19:02 Wed 21 Oct     , Andrew Brygin wrote:
>> Hello Severin,
>>
>> On 21/10/2020 10:17, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> On Tue, 2020-10-20 at 21:14 +0300, Andrew Brygin wrote:
>>>> I have updated the fix according to following comment:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8255003?focusedCommentId=14375484&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14375484
>>>>
>>>> The removal of Java_sun_awt_X11_XToolkit_getDefaultScreenData will be
>>>> tracked as JDK-8251840.
>>>
>>> Thank you!
>>>
>>>> Please take a look to updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~bae/8u/8255003/webrev.01/
>>>
>>> Does this actually build on Windows? I'm thinking not, since it's
>>> missing a mapfile for windows, no?
>>
>> build on windows works fine, because it does not use map files at all:
>>
>> https://hg.openjdk.java.net/jdk8u/jdk8u/file/tip/common/autoconf/flags.m4#l207
>>
> 
> Thanks for confirming this. I did wonder, because I don't remember
> them being used in the old build for Windows.
> 
>>>
>>> How about special case Linux instead and let other platforms use the
>>> old, pre JDK-8250627, mapfile-vers and use the one adding
>>> Java_jdk_internal_platform_cgroupv1_Metrics_isUseContainerSupport on
>>> Linux like so, perhaps?
>>>
>>> https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255003/01/webrev/
>>
>> Actually, only gcc (except macos) and solaris studio toolchains use
>> mapfiles, so this option also looks good.
>>
> 
> I think xlc is AIX? So mapfiles are presumably just for Solaris, Linux
> and *BSD systems other than Mac OS, and there is no need for a -aix copy.

I think so, but I have no AIX to verify this.

> 
> Severin's version would mean less work for any future OS ports, even
> if it is a bit uglier to call out Linux specifically.

yes, I agree, the less number of mapfile copies, the better.

Thanks,
Andrew