8030350 breaks build with older gccs.

[David Holmes]

Hi Volker,

The set of valid platforms and compilers for the OpenJDK should always 
be a sliding window. For JDK 9 "we" want to ditch the "panaoramic 
window" we've been carrying around, move to more recent build platforms 
(which also dictates runtime platforms) and compilers, dropping all the 
old stuff we can. For example on Solaris anything related to the old T1 
threads library; on linux anything to do with the old LinuxThreads 
implementation of pthreads. And cleaning up ancient compiler 
anachronisms in the build logic is also a "good thing".

Now I don't know exactly how that lines up with your legacy support 
goals, but I do think gcc 3.3 is out of scope. There are some 
customization mechanisms in the build logic that should be used (and 
improved where needed) to add additional support for those community 
members that need it.

Just my opinion.

Cheers,
David

On 26/02/2014 7:37 PM, Volker Simonis wrote:
> On Wed, Feb 26, 2014 at 7:29 AM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> Hello Goetz;
>>
>> The earliest version I considered was 4.2. It is unfortunate that these options aren't available on older gcc releases. I think we are going to have to add configure logic to enable them based upon the compiler version found. Whether the code should also be fixed I leave to the hotspot commiters, yourself included.
>>
>> David Holmes does bring a good point about the minimum reasonable or expected gcc version. Even if we do add conditional checks for these options it would,probably quickly get silly with every switch being checked. I picked 4.2 rather arbitrarily based on some other test I saw. I note that the 4.3.x line is almost 6 years old. By the time java 9 is released gcc 4.6 will be about 5 years old. I believe that is about as far back as it is reasonable to support. Requiring 4.6 today would probably be premature even though many are already using 4.8 and reporting 4.9.
>>
>> Unfortunately,  I can't imagine that we could reasonably support both 3.3.3 and 4.9 and all versions in between on all platforms plus whatever comes in the next two years. We need to have a way to trim the set of supported compilers. Suggestions?
>>
>
> I think we should look at the Linux distributions that we want to
> support. For example gcc 3.3.3 was shipped with SLES 9 and gcc 4.1
> with SLES 10. It is part of our (i.e. SAP's) business that we support
> older releases for a long time, that's why we're interested in keeping
> the source base buildable with older releases as well.
>
> I don't think it is too complicated and I don't see any problem in
> adding new compiler options based on the compiler version. This was
> done before and it doesn't affect anybody who is using a newer
> compiler (if you look at the make files you'll even find checks for
> gcc 2). As long as we only speak of new warnings like in this case it
> is trivial to enable them only if they are supported.
>
> That's why I think that Goetz's change
> http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ which fixes
> the makefiles to only use "-Wno-error=format-nonliteral" if available
> is simple, effective and good. I'd only suggest to check for gcc >=
> 4.2 (instead of 4.3) after you wrote that the option already appeared
> in gcc 4.2.
>
> Regards,
> Volker
>
>> Mike
>>
>> On Feb 25, 2014, at 3:42 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:
>>
>>> Hi Mike,
>>>
>>> your change breaks the build with older gccs as they don’t know the option “-Wno-error=format-nonliteral"
>>>
>>> I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64.
>>> Gcc 4.3.4 works.
>>>
>>> In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected
>>> this issue already, or there is a bug to fix this?
>>>
>>> I would propose to fix this by either adapting hotspot code not to issue these warnings:
>>> http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/
>>> or to adapt the makefiles not to use the warning on older gccs:
>>> http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/
>>>
>>> If you give me advice what you would prefer, I will open a bug and send
>>> a RFR.
>>>
>>> Best regards,
>>>    Goetz.
>>>
>>>