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
