This is all correct, thanks David!

For the official toolchains (basically what Oracle builds with), we very much like to keep warnings-as-errors active, because it's a very valuable tool in keeping the code healthy. For other toolchains, it depends, as David says.

We have a mechanism for disabling warnings for specific toolchain types (gcc, clang, solstudio, visualstudio) on a per library basis. We also have the ability to add flags globally for specific toolchain versions in configure, in flags.m4. If we want to solve this by disabling a warning due to a bug in a specific gcc version, I would recommend the latter.

/Erik

On 2018-01-17 14:13, David Holmes wrote:
Adam,

Erik or Magnus from the build team should step in here if this information is wrong but AFAIK the intent is that using the official toolchains the OpenJDK will build out-of-the-box using the supplied instructions and whatever the default settings are (which ideally would be without any warnings).

Anyone building with a different toolchain may encounter problems, and may need to disable warnings-as-errors. That should be in the build docs somewhere if it isn't now.

The build wiki has unfortunately not been updated for JDK 10, but we didn't make any changes to the official toolchains compared to JDK 9:

https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

As gcc 4.8.5 is listed as an "other build platform" I would not have expected you to encounter this problem. Though it is not stated on the wiki whether building on these other platforms requires changing any of the build settings.

If an official, or even semi-official, toolchain encounters a problem then we may look into adding a toolchain specific workaround for the specific file(s) affected (ie disable the specific warning). Otherwise, as "John" (aka Adrian) states we don't play this game for every possible toolchain that may be used.

David

On 17/01/2018 10:56 PM, Adam Farley8 wrote:
Hi John, David,

If you compile jchuff.c  (part of javajpeg) without
"--disable-warnings-as-errors",
then you get an error that kills the build. This is seen in these
circumstances:

Last time this particular discussion came up, the conclusion was that
hunting for warnings is a lost battle as the generated warnings depend
heavily on the toolchain used [1,2].

So, I think for now we're not going to address build errors which occur
when omitting "--disable-warnings-as-errors" in the configure line.

If this is the consensus, then perhaps we should consider setting
--disable-warnings-as-errors by default (in the code), rather than
depending on the user using an option which is not part of the formal
build instructions.

Thoughts?

Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Reply via email to