Re: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf
On 2018-01-18 19:37, Erik Joelsson wrote: Hello Magnus, Nice to see this finally happening! Thanks! In building.md, when getting autoconf for Cygwin, I believe you also need the autoconf wrapper scripts package. Hm, well, no, it's the other way around. "autoconf" is the name of the cygwin "autoconf wrapper scripts" package. It depends on "m4", "autoconf2.69" (or whatever), etc. I have verified that just installing "autoconf" will be enough, and will pull in all needed dependencies. Perhaps it's also worth mentioning that you can download the autoconf src and build/install from there? Well, I'm already giving a link to http://www.gnu.org/software/autoconf in the build readme. I'm not sure if it's helpful for anyone to download the autoconf source by themselves. Most users will have it available prebuilt. And if not, you'll also most likely need to pull down and build m4, and that's trickier. The reason why we used to download autoconf and build it from source was to make sure that we got the exactly right version, but that only made sense when we checked in the generated-configure.sh. (And this worked fine for us, since we had m4...) In jib-profiles.js, you need to use build_platform instead of target_platform when creating the module name for the dependency. Good point. Fixed. I would also like if you added the dependency on the other main profiles as well. At least linux-x86, linux-arm64 and windows-x86 are still possible to build and should work fine with this. For solaris-x64 you would need to generate the package for it to work. Sure. The TMPDIR logic looks weird. Are you unconditionally setting it to /cygdrive/t/...? That's a valid dir in our build farm, but not on my local windows box: mkdir: cannot create directory ‘/cygdrive/t’: No such file or directory autom4te: cannot create /cygdrive/t/workspace/.build/tmpdir/am4t7009.7040: No such file or directory at /cygdrive/c/cygwin64/var/tmp/jib-erik/install/jpg/infra/builddeps/autoconf-windows_x64/2.69+1.0.1/autoconf-windows_x64-2.69+1.0.1.tar.gz/usr/bin/autom4te line 954. Error: Failed to generate runnable configure script Yeah, that was broken by design. :-( Some offline discussion later, it turned out that the reason for the trouble was mismatch between cygwin-32 and cygwin-64. I've solved this by generating two different packages, for cygwin-32 and cygwin-64. I've also made some other minor fixes to the build script, e.g. using perl instead of sed due to the braindead sed being available on solaris. :( Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generated-configure/webrev.02/ /Magnus /Erik On 2018-01-18 05:28, Magnus Ihse Bursie wrote: Currently, we require all developers who modify the configure script to run autoconf locally, to update the generated-configure.sh script, which is then checked in. This is the only instance of checked in "compiled" code in OpenJDK, and this has brought along several problems: * Only a specific version of autoconf, 2.69, can be used, to avoid large code changes in the generated file. Unfortunately, Ubuntu ships a version of autoconf that claims to be 2.69 but is actually heavily patched. This requires all Ubuntu users to compiler their own autoconf from source. * The Oracle JDK closed sources has a closed version that needs to be updated. In practice, this has meant that all non-Oracle developers, need an Oracle sponsor for patches modifying the configure script. * If the configure script is not properly updated, the build will fail. The same happens on the Oracle side if the closed version is not in sync with the open version. It is easy to miss re-generating the script after the last fix of a typo in the comments in an .m4 file... * Merging between two changes containing configure modifications is almost impossible. In practice, the entire generated-configure.sh needs to be thrown away and regenerated. The entire benefit of having the file in the repo is to save first-time developers the hassle of installing autoconf. On most platforms, this is a no-brainer (like "apt install autoconf"), and the requirement is similar to other open source projects using autoconf and "./configure". It's just not worth it. Bug: https://bugs.openjdk.java.net/browse/JDK-8195689 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generated-configure/webrev.01 /Magnus
Re: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
Build change looks fine. /Erik On 2018-01-25 10:46, Gary Adams wrote: Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS build flag and update the winsock deprecated functions. Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 Webrev: http://cr.openjdk.java.net/~gadams/8080990/ These are the initial deprecated functions updated: gethostbyname -> getaddrinfo inet_addr -> inet_pton inet_ntoa -> inet_ntop I'm not sure how to replace the existing WSASendDisconnect calls. It's not clear that it actually provides a graceful disconnect.
RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS build flag and update the winsock deprecated functions. Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 Webrev: http://cr.openjdk.java.net/~gadams/8080990/ These are the initial deprecated functions updated: gethostbyname -> getaddrinfo inet_addr -> inet_pton inet_ntoa -> inet_ntop I'm not sure how to replace the existing WSASendDisconnect calls. It's not clear that it actually provides a graceful disconnect.
Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c
The claim on the wiki was made by Volker on July 13 2017. It was done on SuSE linux while the reported problem is on zLinux. Maybe they have different vendor specific patches in their respective gcc builds? Is SAP still able to build without --disable-warnings-as-errors? This wiki is supposed to be a community effort. /Erik On 2018-01-24 16:37, David Holmes wrote: Hi Magnus, On 25/01/2018 9:55 AM, Magnus Ihse Bursie wrote: I'm not sure I'm able to follow where this discussion is heading, but at the very least I'd like to chime in on the patch below: I don't like how the entire DISABLED_WARNINGS_gcc line is lifted out. A better solution is something like this: ifeq ($(CC_VERSION_NUMBER), 4.8.5) #Turn off array-bounds warnings for libjava compilation because jchuff.c #fails to compile on gcc 4.8.5 with a warning that an array is potentially #out of bounds. This kills a warnings=errors build. LIBJAVAJPEG_DISABLED_WARNINGS_gcc485 := array-bounds endif ... DISABLED_WARNINGS_gcc := clobbered $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc485), \ I also can't see this going into anything else than the current mainline, jdk/jdk i.e. JDK 11. Since the issue is trivially avoided by using --disable-warnings-as-errors, I hardly see that it warrants a backport. It's pointless in JDK 11 as we're not going to claim support for gcc 4.8.5. The issue is that out-of-the-box if you are building 8u or 9 and use gcc 4.8.5, which is supposed to be a valid compiler to use based on the wiki, then it fails because of this gcc bug, unless you disable warnings-as-errors. So either we put in a workaround for the bug or we update to the build docs (and/or the wiki) to make it very clear that you may need to disable warnings-as-errors (something there is no mention of in the build doc in 9). David - /Magnus On 2018-01-23 14:44, Adam Farley8 wrote: Hi All, All: I think I responded to everyone below. Please could a committer or author raise a bug and, if people are happy with this change, line it up for contribution to JDKs 8-11 (assuming 4.8.5 is still the recommended gcc for JDK10 and 11 on SUSE sles)? Erik: One toolchain-specific change, as requested. This was tested on JDK9, so please apply an offset of -1 to the line numbers before applying to JDK10. --- Start of Diff --- diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -482,6 +482,14 @@ BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) endif +LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered +ifeq ($(CC_VERSION_NUMBER), 4.8.5) + #Turn off array-bounds warnings for libjava compilation because jchuff.c + #fails to compile on gcc 4.8.5 with a warning that an array is potentially + #out of bounds. This kills a warnings=errors build. + LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered array-bounds +endif + $(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ LIBRARY := javajpeg, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ @@ -491,7 +499,7 @@ CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ $(LIBJAVA_HEADER_FLAGS) \ -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ - DISABLED_WARNINGS_gcc := clobbered, \ + DISABLED_WARNINGS_gcc := $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc), \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ --- End of Diff --- Phil: I've changed the title as asked and supplied the diff above. However, I can't upload files to cr.openjdk.java.net, nor can I create bugs myself. I understand that authors and committers can, but I don't have those privileges yet. Be nice if I did. :) John: I read your email, and I understand your position. I disagree with it, but I understand it. 4.8.5 is an old version of gcc, but right now it is the listed gcc version for SUSE sles on intel, ppc, ppcle, and zLinux. Even if this is not the case for JDK 10 or 11, we should ensure this fix is fully propagated to ensure consistent behaviour. That is my position. David: Thanks for the URL. I agree with your position on 4.8.5 gcc needing to compile OpenJDK without errors or special options. :) Best Regards Adam Farley From: Phil Race To: Adam Farley8 , 2d-...@openjdk.java.net Cc: build-dev Date: 18/01/2018 19:16 Subject: Re: [OpenJDK 2D-Dev] [PATCH] Build fails to compile jchuff.c Try again with build-dev cc'd .. -phil. On 01/18/2018 11:14 AM, Phil Race wrote: I agree with what Erik said on build-dev that being specific about the tool chain and the reason are worthwhile and important. We've done that in similar cases. Also these review threads usually should have a subject like RFR: : which means you first n
