8030350 breaks build with older gccs.
goetz.lindenmaier at sap.com
Wed Feb 26 14:22:53 PST 2014
currently, the build with 4.8 issues a warning. The flag just avoids that the
warning is treated as error.
So I thought removing the warning is the best way - as this is anyways
the path currently followed, right? (Although the code looks better without
But if you don't like the special case for older compilers (which I just reuse,
it's there anyways!), you can also switch off the warning for all compilers.
By the way, 4.1.2 knows -Wno-error and -Wformat-nonliteral, but not the
From: Volker Simonis [mailto:volker.simonis at gmail.com]
Sent: Wednesday, February 26, 2014 10:37 AM
To: Mike Duigou
Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
Subject: Re: 8030350 breaks build with older gccs.
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.
> 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:
>> or to adapt the makefiles not to use the warning on older gccs:
>> If you give me advice what you would prefer, I will open a bug and send
>> a RFR.
>> Best regards,
More information about the hotspot-dev