[PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
Hi All, 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: Build: JDK9 gcc and g++ Version: 4.8.5 Platform: zLinux 64bit (s390x) The error message is: /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: In function 'jGenOptTbl': /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: error: array subscript is below array bounds [-Werror=array-bounds] while (bits[j] == 0) ^ It looks to me that this error happens because the while loop can technically reduce j down to beneath 0, resulting in us attempting to find the array entry with index -1. On the basis that if we get down to -1 here bad things will happen regardless, perhaps we should change that line to: while ((bits[j] == 0) && (j != 0)) This appears to prevent the compiler failing with this error, by providing unambiguous handling for the "index -1" scenario. 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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
Hi Adam! On 01/17/2018 12:50 PM, Adam Farley8 wrote: 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. Cheers, Adrian [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-January/029754.html [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-January/029756.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
Hi Adam, This seems to be a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 I'm assuming that the code is actually written in such a way that the index will never actually go negative (due to what has been written previously). The right fix here would be to disable the warning in gcc 4.x. David On 17/01/2018 9:50 PM, Adam Farley8 wrote: Hi All, 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: Build: JDK9 gcc and g++ Version: 4.8.5 Platform: zLinux 64bit (s390x) The error message is: /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: In function 'jGenOptTbl': /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: error: array subscript is below array bounds [-Werror=array-bounds] while (bits[j] == 0) ^ It looks to me that this error happens because the while loop can technically reduce j down to beneath 0, resulting in us attempting to find the array entry with index -1. On the basis that if we get down to -1 here bad things will happen regardless, perhaps we should change that line to: while ((bits[j] == 0) && (j != 0)) This appears to prevent the compiler failing with this error, by providing unambiguous handling for the "index -1" scenario. 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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
On 01/17/2018 01:56 PM, Adam Farley8 wrote: 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. I'm not sure why. Building OpenJDK from source isn't exactly something that is done by normal users. If someone is willing to hack on the OpenJDK code base, I would assume they know about -Werror and similar options and how to control them. I mean, yes, you can change that to have -Werror turned off by default, but having the compiler complain less is usually a bad idea. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
>> 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. >I'm not sure why. Because the default build instructions don't work in this scenario, and if all the effort to impliment a clone-config-make model was intended to encourage more users to attempt a local build (in order to try their hand at a fixing a bug themselves or something) it makes sense to me to try to maintain a scenario where OpenJDK can build to completion across a wide variety of toolchains. >Building OpenJDK from source isn't exactly something >that is done by normal users. If someone is willing to hack on the OpenJDK >code base, I would assume they know about -Werror and similar options and >how to control them. I don't agree. Someone should not have to be familiar with gcc options in order to fix a typo, or change some Java code. And besides, we have a clear and simple four-step build process (clone, get source, configure, make). Why would we want people to have to fail their build and experiment with different options, when we can fix the problem right here and now. >I mean, yes, you can change that to have -Werror turned off by default, >but having the compiler complain less is usually a bad idea. In general, yes. In this one compile it's breaking the build. David suggested disabling this warning. The simplest way I see to do this is to change Awt2dLibraries.gmk. The code is here: $(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ LIBRARY := javajpeg, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBJAVAJPEG_SRC), \ INCLUDE_FILES := $(BUILD_LIBJAVAJPEG_INCLUDE_FILES), \ OPTIMIZATION := HIGHEST, \ Switching the OPTIMIZATION to LOW will solve this at a stroke. 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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
On 01/17/2018 03:07 PM, Adam Farley8 wrote: Because the default build instructions don't work in this scenario, and if all the effort to impliment a clone-config-make model was intended to encourage more users to attempt a local build (in order to try their hand at a fixing a bug themselves or something) it makes sense to me to try to maintain a scenario where OpenJDK can build to completion across a wide variety of toolchains. There are other, higher hurdles which you have to overcome in order to be able to contribute patches, i.e. signing the OCA. If OpenJDK was a project hosted on github where drive-by patches are more common, you would have a point. Building OpenJDK from source isn't exactly something that is done by normal users. If someone is willing to hack on the OpenJDK code base, I would assume they know about -Werror and similar options and how to control them. I don't agree. Someone should not have to be familiar with gcc options in order to fix a typo, or change some Java code. And besides, we have a clear and simple four-step build process (clone, get source, configure, make). Why would we want people to have to fail their build and experiment with different options, when we can fix the problem right here and now. Because "-Werror" isn't some obscure option. It's something very common that every C/C++ developer should know about. Also, you don't need to rebuild the whole JDK to contribute a patch to fix an obvious typo. I mean, yes, you can change that to have -Werror turned off by default, but having the compiler complain less is usually a bad idea. In general, yes. In this one compile it's breaking the build. David suggested disabling this warning. The simplest way I see to do this is to change Awt2dLibraries.gmk. The code is here: $(_eval_ $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ LIBRARY := _javajpeg_, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBJAVAJPEG_SRC), \ INCLUDE_FILES := $(BUILD_LIBJAVAJPEG_INCLUDE_FILES), \ OPTIMIZATION := HIGHEST, \ Switching the OPTIMIZATION to LOW will solve this at a stroke. First you said you want to disable -Werror by default and make all warnings non-fatal and now you want to address one particular warning. I'm confused. As mentioned in another discussion I linked, hunting for individual warnings a lost battle with all the different toolchains downstreams are going to use. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
> Switching the OPTIMIZATION to LOW will solve this at a stroke. And regress performance for all platforms I expect in a case where performance matters .. in order to work around a gcc bug ? I don't think so. Disabling the specific error with the specific tool chain is the only acceptable option I can think of. And bear in mind build-dev is not the keeper of the JPEG libraries. 2d-dev is the right place. -phil. On 1/17/18, 6:07 AM, Adam Farley8 wrote: 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. I'm not sure why. Because the default build instructions don't work in this scenario, and if all the effort to impliment a clone-config-make model was intended to encourage more users to attempt a local build (in order to try their hand at a fixing a bug themselves or something) it makes sense to me to try to maintain a scenario where OpenJDK can build to completion across a wide variety of toolchains. Building OpenJDK from source isn't exactly something that is done by normal users. If someone is willing to hack on the OpenJDK code base, I would assume they know about -Werror and similar options and how to control them. I don't agree. Someone should not have to be familiar with gcc options in order to fix a typo, or change some Java code. And besides, we have a clear and simple four-step build process (clone, get source, configure, make). Why would we want people to have to fail their build and experiment with different options, when we can fix the problem right here and now. I mean, yes, you can change that to have -Werror turned off by default, but having the compiler complain less is usually a bad idea. In general, yes. In this one compile it's breaking the build. David suggested disabling this warning. The simplest way I see to do this is to change Awt2dLibraries.gmk. The code is here: $(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ LIBRARY := javajpeg, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBJAVAJPEG_SRC), \ INCLUDE_FILES := $(BUILD_LIBJAVAJPEG_INCLUDE_FILES), \ OPTIMIZATION := HIGHEST, \ Switching the OPTIMIZATION to LOW will solve this at a stroke. 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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
>> Switching the OPTIMIZATION to LOW will solve this at a stroke. > >And regress performance for all platforms I expect in a case where >performance matters .. >in order to work around a gcc bug ? I don't think so. I wasn't considering the performance impact on java jpeg. A fair statement. >Disabling the specific error with the specific tool chain is the only >acceptable option I can think of. I'll look into that. >And bear in mind build-dev is not the keeper of the JPEG libraries. >2d-dev is the right place. > >-phil. Also fair. I will send an email to 2d-dev with the same title. Figured I'd start here because it breaks all builds that don't use disable-warnings-as-errors. Thank you everyone for your time. Feel free to follow these adventures on 2d-dev. :) 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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
Hi All I sent an email to the 2d-dev list yesterday, but I'll respond here as well so you guys know I'm not ignoring you. :) > 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 This is correct. In flags.m4, GCC has a potential DISABLE_WARNING_PREFIX value of "-Wno-". Yesterday I posted to 2d-dev and recommended changing Awt2dLibraries.gmk, which supplies suffixes for that prefix Basically you change line 494 to this: DISABLED_WARNINGS_gcc := clobbered array-bounds, \ This puts a -Wno-array-bounds on the gcc compile command for jchuff.c, thereby ignoring the error-warning I'm seeing. I ran a build to confirm this works. It did, and the build completed without further errors. This fix, if accepted, means --disable-warnings-as-errors will not be needed in future zLinux compiles using this gcc (which, as David points out, is the gcc version on the build list). Just "bash ./compile" and "make all". Simples! Please send future responses through my email to the 2d-dev list. http://mail.openjdk.java.net/pipermail/2d-dev/2018-January/008836.html Thanks for your time. :) 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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
Hello Adam, When adding a disabled warning like this, we need to also add a clear comment describing why it's necessary. In this case it's caused by a bug in GCC and only affects certain versions. Otherwise, we will likely try to remove them later and without information on why it was added, we will just conclude that the warning is not triggering with the official GCC version and remove it. If the affected versions is limited, then we may also consider making this conditional on the GCC version. The version is available in the variables TOOLCHAIN_VERSION, CC_VERSION_NUMBER and CXX_VERSION_NUMBER. /Erik On 2018-01-18 03:15, Adam Farley8 wrote: Hi All I sent an email to the 2d-dev list yesterday, but I'll respond here as well so you guys know I'm not ignoring you. :) > 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 This is correct. In flags.m4, GCC has a potential DISABLE_WARNING_PREFIX value of "-Wno-". Yesterday I posted to 2d-dev and recommended changing Awt2dLibraries.gmk, which supplies suffixes for that prefix Basically you change line 494 to this: DISABLED_WARNINGS_gcc := clobbered array-bounds, \ This puts a -Wno-array-bounds on the gcc compile command for jchuff.c, thereby ignoring the error-warning I'm seeing. I ran a build to confirm this works. It did, and the build completed without further errors. This fix, if accepted, means --disable-warnings-as-errors will not be needed in future zLinux compiles using this gcc (which, as David points out, is the gcc version on the build list). Just "bash ./compile" and "make all". Simples! Please send future responses through my email to the 2d-dev list. http://mail.openjdk.java.net/pipermail/2d-dev/2018-January/008836.html Thanks for your time. :) 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
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
Hi! On 01/18/2018 06:27 PM, Erik Joelsson wrote: When adding a disabled warning like this, we need to also add a clear comment describing why it's necessary. In this case it's caused by a bug in GCC and only affects certain versions. Otherwise, we will likely try to remove them later and without information on why it was added, we will just conclude that the warning is not triggering with the official GCC version and remove it. I don't quite understand why we would want to patch OpenJDK-11 in the first place when the reason this bug is triggered is a) a known toolchain bug in an old and unsupported version of gcc and b) can be easily disabled by building with "--disable-warnings-as-errors". The only thing here to patch is obviously gcc and not any other project that is built with gcc. I am pretty confident that OpenJDK isn't the only project that is affected by this particular gcc bug. And if a Linux distribution is using gcc-4.8.5 as their default compiler, they will most likely not be using OpenJDK-11 but rather be stuck with OpenJDK-7 or 8. Thus, I don't see a point in working around bugs in an ancient toolchain in the current OpenJDK code. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux
On 2018-01-17 15:07, Adam Farley8 wrote:
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.
I'm not sure why.
Because the default build instructions don't work in this scenario, and
if all the effort to impliment a clone-config-make model was intended to
encourage more users to attempt a local build (in order to try their hand
at a fixing a bug themselves or something) it makes sense to me to try
to maintain a scenario where OpenJDK can build to completion across a wide
variety of toolchains.
I'm not sure what you mean by that the "default build instrictions don't
work". When the build fails due to a warning and you have not disabled
warnings as error, the build output looks like this:
ERROR: Build failed for target 'jdk' in configuration 'linux-x64' (exit
code 2)
=== Output from failing command(s) repeated here ===
* For target support_native_jdk.management_libmanagement_ext_Flag.o:
/localhome/hg/jdk-ALT/open/src/jdk.management/share/native/libmanagement_ext/Flag.c:
In function 'heh':
/localhome/hg/jdk-ALT/open/src/jdk.management/share/native/libmanagement_ext/Flag.c:37:10:
error: comparison of unsigned expression < 0 is always false
[-Werror=type-limits]
if (hest < 0) {
^
cc1: all warnings being treated as errors
* All command lines available in
/localhome/hg/jdk-ALT/build/linux-x64/make-support/failure-logs.
=== End of repeated output ===
=== Make failed targets repeated here ===
Lib-jdk.management.gmk:56: recipe for target
'/localhome/hg/jdk-ALT/build/linux-x64/support/native/jdk.management/libmanagement_ext/Flag.o'
failed
make/Main.gmk:226: recipe for target 'jdk.management-libs' failed
=== End of repeated output ===
Hint: Try searching the build log for the name of the first failed target.
Hint: See doc/building.html#troubleshooting for assistance.
I don't think it requires much of an effort or capacity as a programmer
to figure out that this is a warning, which was turned into an error. At
the very last line before your prompt, you are also given a very good
suggestion. And very much so, the troubleshooting chapter does indeed
have a section on "Fixing Unexpected Build Failures" where
--disable-warnings-as-errors are suggested.
If by "default" you mean that you only read like the top part of the
document:
"TL;DR (Instructions for the Impatient)
If you are eager to try out building OpenJDK, these simple steps works
most of the time."
but missed out the "most of the time" or the "If any of these steps
failed, or if you want to know more about build requirements or build
functionality, please continue reading this document." following after
the just 5 numbered items, then I don't know what will help you.
We try really hard to make the build experience easy, pleasant and
simple, but there is no way that everything is ever going to work
perfectly straight out of the box for anyone. Especially not if they are
using exotic or unusal hardware or software. In those cases, reading the
documentation is necessary, as for all software projects.
/Magnus
Building OpenJDK from source isn't exactly something
that is done by normal users. If someone is willing to hack on the
OpenJDK
code base, I would assume they know about -Werror and similar options and
how to control them.
I don't agree. Someone should not have to be familiar with gcc options in
order to fix a typo, or change some Java code. And besides, we have a
clear
and simple four-step build process (clone, get source, configure, make).
Why would we want people to have to fail their build and experiment with
different options, when we can fix the problem right here and now.
I mean, yes, you can change that to have -Werror turned off by default,
but having the compiler complain less is usually a bad idea.
In general, yes. In this one compile it's breaking the build.
David suggested disabling this warning. The simplest way I see to do this
is to change Awt2dLibraries.gmk.
The code is here:
$(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \
LIBRARY := javajpeg, \
OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
SRC := $(LIBJAVAJPEG_SRC), \
INCLUDE_FILES := $(BUILD_LIBJAVAJPEG_INCLUDE_FILES), \
OPTIMIZATION := HIGHEST, \
Switching the OPTIMIZATION to LOW will solve this at a stroke.
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
