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
