[PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

[Magnus Ihse Bursie]

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