OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

Hi , was anyone seen the following issue ? After an update from autoconf 2.71 to 2.72 on macOS (x86_6$9 , the C++ flag detection changed in an unexpected way .It is an OpenJDK11 build . Previously with (autoconf 2.71) we had : checking for /jenkins/workspace/devkit-xcode-13

RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

Barrett Sent: Tuesday, 2 January 2024 22:35 To: Baesken, Matthias Cc: build-dev@openjdk.org; Magnus Ihse Bursie ; Langer, Christoph ; Erik Joelsson Subject: Re: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option * PGP Signed by an unknown key > On Jan 2, 2024, at 4:19 AM,

RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

Autoconf 2.70) but the issue mentions 2.70, we only saw this with 2.72 . Best regards, Matthias -Original Message- From: Baesken, Matthias Sent: Wednesday, 3 January 2024 08:48 To: 'Kim Barrett' Cc: build-dev@openjdk.org; Magnus Ihse Bursie ; Langer, Christoph ; Erik Joelsson

RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

>So autoconf forcibly selects a -std= option, possibly overriding either an >explicit option or the compiler's default. Who thought that was a good idea? >There are even comments from the time that question that "feature". > >It looks like there is code to attempt to deal with that sort of thing

RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

Btw. Is there already something at make/autoconf that does similar filtering of unwanted flags ? The mentioned TOOLCHAIN_POST_DETECTION seems just to reset some variables like CXX_CFLAGS to old values , not sure if this is what we want here ? >Hi Erik, I created : > >https://bugs.openjdk.

RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

>> >> It looks like there is code to attempt to deal with that sort of thing in our >> build system. See TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4. >> That >> dates back to JDK 9. However, that only deals with CFLAGS and CXXFLAGS. The >> AC_PROG_CC/CXX feature affects the CC/CXX varia

RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

Seems there is already an util helper " UTIL_GET_NON_MATCHING_VALUES" . So should we do something like this (maybe with a few more unwanted -std= settings ? Seems the UTIL_GET_NON_MATCHING_VALUES so far accepts only fix strings, is that correct ? diff --git a/make/autoconf/toolchain.m

RE: OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

Thanks , I created https://github.com/openjdk/jdk/pull/17301 . Best regards, Matthias -Original Message- From: erik.joels...@oracle.com Sent: Friday, 5 January 2024 19:10 To: Baesken, Matthias ; Kim Barrett Cc: build-dev@openjdk.org; Magnus Ihse Bursie ; Langer, Christoph

CFV: New Build Group Member: Christoph Langer

I hereby nominate Christoph Langer (clanger) to Membership in the Build Group. Christoph is a long standing member of the JVM team at SAP and a long time OpenJDK contributor [3]. He is a member of the OpenJDK Members Group and the Vulnerability Group, and Reviewer in a number of projects. Chris

RE: CFV: New Build Group Member: Christoph Langer

Vote: yes Best regards, Matthias >I hereby nominate Christoph Langer (clanger) to Membership in the Build Group.

Result: New Build Group Member: Christoph Langer

The vote for Christoph Langer [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus voting, this is sufficient to approve the nomination. [1] https://mail.openjdk.org/pipermail/build-dev/2024-January/042845.html Best regards, Matthias >I hereby no

RE: Add "Windows aarch64" to Supported Build Platforms

Hi Brian , if you give me the detailled info I can add it . Best regards, Matthias -- Hello, We would like to add Microsoft as the maintainer of Windows aarch64 to the Supported Build Platforms[1] page (JDK versions 11/17/21

RE: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables

Joelsson Sent: Wednesday, 7 August 2024 13:58 To: Baesken, Matthias ; Magnus Ihse Bursie Subject: Re: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables Hello Matthias, If you had sent this to build-dev, you would have received an answer much quicker as

RE: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables

Hi Erik, the '--release N-1' sounds like a good idea ; where do we have to set it ? Best regards, Matthias >To me that sounds like GHA are miss-configured for the update releases. To >work around this, perhaps we should set an explicit '--release N-1' argument >when building source intende

RE: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables

You mean instead of BOOT_JDK_SOURCETARGET use BOOT_JDK_RELEASETARGET (and set '--release N-1' there) ? Best regards, Matthias From: Erik Joelsson Sent: Monday, 12 August 2024 14:30 To: Baesken, Matthias ; Magnus Ihse Bursie ; build-dev@openjdk.org Subject: Re: [Exte

RE: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables

I created https://bugs.openjdk.org/browse/JDK-8338205 8338205: replace BOOT_JDK_SOURCETARGET Best regards, Matthias >Something like that yes. Maybe just BOOT_JDK_RELEASE, or possibly >BOOT_JDK_RELEASE_FLAG?

RE: [External] : RE: jdk21u-dev build issue : 8326332: Unclosed inline tags cause misalignment in summary tables

Unfortunately using --release is not working in our build. We run very soon into this error : error: exporting a package from system module java.base is not allowed with --release Best regards, Matthias >I created > >https://bugs.openjdk.org/browse/JDK-8338205 >8338205: replace BOOT_JDK_SOU

MSAN memory sanitizer and OpenJDK

Hello , I thought about MSAN memory sanitizer and OpenJDK. See https://clang.llvm.org/docs/MemorySanitizer.html https://github.com/google/sanitizers/wiki/MemorySanitizer We have already some sanitizer support in OpenJDK e.g. for ASAN (address) and UBSAN (undefined behavior). Would MSAN be s

gold linker issues / devkit ?

After switching the OpenJDK build to a Fedora devkit (from non-devkit Ubuntu based build) , we were running into issues described here : https://github.com/SAP/SapMachine/issues/1227 and here : https://github.com/eclipse-platform/eclipse.platform.swt/issues/321 When using the gold linker se

references to hg

Hello, I noticed still a few references to hg in current openjdk subtree make, I wonder should we remove / replace them ? Some of those : make/autoconf/basic.m4 AC_MSG_ERROR([Bad file permissions on src files. This is usually caused by cloning the repositories with a non cygwin hg in a dire

RE: references to hg

Hi Erik, thanks for the feedback. I created : https://bugs.openjdk.org/browse/JDK-8294748 8294748 : Cleanup unneeded references to hg Best regards, Matthias --- snip - make/autoconf/spec.gmk.in 772 HG:=@HG@ make/autoconf/basic_tools.m4

configure checks for package handler tools on Windows

Hello , currently we check in make/autoconf/help.m4 for a couple of well known package handler tools : AC_DEFUN_ONCE([HELP_SETUP_DEPENDENCY_HELP], [ UTIL_LOOKUP_PROGS(PKGHANDLER, zypper apt-get yum brew port pkgutil pkgadd pacman apk) ]) This might be a great thing on UNIX/Mac , but on Wind

Double '$' in jdk/make/RunTests.gmk

Hi, I noticed a double usage of ‘$’ in jdk/make/RunTests.gmk 800 ifeq ($$(call isTargetOs, windows), true) 801 $1_JTREG_BASIC_OPTIONS += -e:_NT_SYMBOL_PATH Is there some good reason for this, the other call isTargetOs - snippets in the Makefiles do not use $$? Best regards, Ma

jdk.javadoc - usage of jdk11 coding Path.of in the jdk11 build

Hi, we were running recently into this build error in jdk11u-dev when a BOOTSTRAP JDK10 was used : …\jdk11u-dev\src\jdk.javadoc\share\classes\jdk\javadoc\internal\doclets\formats\html\HtmlDoclet.java:253: error: cannot find symbol legalNoticesDir = Path.of(legalNotices)

jdk build using devkit on RHEL puts path to devkit into libsplashscreen

Hello, by chance we noticed that a jdk build on RHEL Linux (ppc64le if that matters) that uses a devkit puts the devkits folder into the libsplashscreen.so binary . See those objdump and ldd output : objdump -x ./lib/libsplashscreen.so | grep PATH RUNPATH /mydev

RE: [External] : jdk build using devkit on RHEL puts path to devkit into libsplashscreen

Hi Erik, thanks for the fast reply . I created https://bugs.openjdk.org/browse/JDK-8315499 Best regards, Matthias From: erik.joels...@oracle.com Sent: Thursday, 31 August 2023 15:30 To: Baesken, Matthias ; build-dev@openjdk.org; sgehwolf Cc: Zeller, Arno Subject: Re: [External] : jdk build

error extraction form build log (in case of bash: Permission denied error on Windows)

Hello, A Windows build failed because of some temporary "Permission denied" issue we see sometimes on Windows. Unfortunately at the end of the log not much info is found, the error is not reported there . . if /usr/bin/grep -q "recipe for target .* failed" ... No indication of failed

RE: error extraction form build log (in case of bash: Permission denied error on Windows)

using this pattern ? ( but maybe this would be too easy ) Best regards, Matthias From: Magnus Ihse Bursie Sent: Wednesday, 13 September 2023 15:18 To: Baesken, Matthias ; build-dev@openjdk.org Cc: Zeller, Arno Subject: Re: error extraction form build log (in case of bash: Permission denied error

unused and set but not used variable warnings when building with toolchain clang on Linux

Hi, I came across some warnings as errors today when trying to build on Linux with toolchain clang (clang 15 on USE Linux) : jdk/src/jdk.jpackage/share/native/common/Log.cpp:46:28: error: unused variable 'defaultLogLevel' [-Werror,-Wunused-const-variable] const Logger::LogLevel defa

ubsan minimal runtime option and OpenJDK

Hi, I wanted to try the "minimal runtime" option of ubsan because it might be faster and has other benefits. See https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#minimal-runtime Unfortunately it seems to be available only with clang on Linux, not (yet?) gcc, so I configured --with-ad

RE: hsdis build

* Please open an issue in JBS. * I created https://bugs.openjdk.org/browse/JDK-8343186 8343186: Hsdis build libopcodes and libbfd are not found

RE: hsdis build

>> Another issue on my SUSE Linux box was that libopcodes.a was not detected >> correctly when using a pre-built binutils dir. The folder lib was >> taking but this one was in lib64 . >If you believe this to be a bug, please open a JBS issue. At least the error output is bad , it says :

RE: ubsan minimal runtime option and OpenJDK

>I'd say it looks like you need to link with another library? Where should the >__ubsan_handle_type_mismatch_minimal symbol come from? I don’t really know. Was wondering if anyone had already worked with this more. >>On the other hand, I tried the minimal runtime option with some standalone

hsdis build

Hello, I wanted to try the hsdis build (on Linux x86_64) . After no success my system binutils, I downloaded the sources and used these configure options : --with-hsdis=binutils --with-binutils-src=/mydir/binutils/binutils-2.42.90 The configure part does not complain, and seems the binuti

Disabling JVM features like for example jvmci or cds

Hi, I wanted to try to build a JVM on Linux x86_64 with JVMCI disabled (just to check how the JVM behaves in a test). The configure help output shows a long list how to enable those features --enable-jvm-feature-cds enable jvm feature 'cds' (enable class data sharing

RE: Disabling JVM features like for example jvmci or cds

>I think `--disable-xxx` is the more usual autoconf way. Though expecting >users to just know that doesn't seem right, so having the help text say >something about it seems like a good idea. >But the relevant help text is probably (mostly?) automatically generated by >the built-in autoconf too

github repo hash in the binaries and hserr file ?

Hello, I wonder if there is / was already an attempt to compile the github repo hash into the binaries and later also output it in the hserr / hsinfo file ? I would consider the information helpful for identification of the matching sources (e.g. matching to the source files mentioned in the

RE: broken dependencies when doing make all ?

>And the problem still persisted..? No, just the incremental build was bad ; after rm -rf and full rebuild everything was fine . Best regards, Matthias

broken dependencies when doing make all ?

Hello, I was running on Linux into this issue today : make all Building target 'all' in configuration '/builddir' gmake[3]: *** No rule to make target '/builddir/support/interim-image/bin/java', needed by '/builddir/support/link_opt/classlist'. Stop. gmake[2]: *** [make/Main.gmk:649: generate

RE: clang Memory sanitizer (msan) and OpenJDK

I installed the llvm package to get the /usr/bin/llvm-symbolizer (this seems to be needed to get meaningful stacks) . Brought back the visibility=hidden settings, seems they do no harm to msan . However the removal of -Wl,--exclude-libs,ALL is needed. With the llvm-symbolizer add

clang Memory sanitizer (msan) and OpenJDK

Hi, Memory sanitizer https://clang.llvm.org/docs/MemorySanitizer.html is supported with the clang toolchain (e.g. on Linux) ; “MemorySanitizer is a detector of uninitialized memory use” . For small examples it is rather easy to use, you just compile and link with -fsanitize=memory

RE: clang Memory sanitizer (msan) and OpenJDK

22:06 To: Baesken, Matthias ; build-dev@openjdk.org Subject: Re: clang Memory sanitizer (msan) and OpenJDK I thought I recognized this issue, and started searching the mail archive. Seems the same question was asked last year by ... you. :-) https://mail.openjdk.org/pipermail/build-dev/2024-A

RE: clang Memory sanitizer (msan) and OpenJDK

>>Maybe you can try patching out -fvisibility=hidden from the compile command >>line to see if that makes any difference. >Sounds like a good idea to start with, I will try this! Seems the visibility >stuff plays a role here. I removed the -fvisibility=hidden from make/autoconf/flags-cflag

RE: clang Memory sanitizer (msan) and OpenJDK

I checked the link call for javac . /usr/bin/clang -fuse-ld=lld -fuse-ld=lld -Wl,--exclude-libs,ALL -Wl,-z,noexecstack -m64 -fsanitize=memory Could it be that the -Wl,--exclude-libs,ALL“hides” the msan symbols like __msan_param_tlsfrom exporting ? But I guess we set thi

RE: clang Memory sanitizer (msan) and OpenJDK

>Could it be that the -Wl,--exclude-libs,ALL“hides” the msan symbols >like __msan_param_tlsfrom exporting ? >But I guess we set this for a reason so removing it might cause other trouble ? Seems the -Wl,--exclude-libs,ALL is the setting that caused the msan build issue, when I r

LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug symbols

Hello, while looking at the JDK native lib optimization levels, I noticed this special setting : make/modules/java.management/Lib.gmk ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true) LIBMANAGEMENT_OPTIMIZATION := LOW endif Why is it there ? I removed it in out inter

RE: LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug symbols

* I very much doubt it's needed, but it does mean that this lib has been compiled at "LOW" for most, if not all, relevant builds of OpenJDK since then. If I create a PR removing this special handling, could you please test it in your CI to be sure that nothing bad happens ? Best regards,

RE: broken dependencies when doing make all ?

> Did you try to run "make doctor"? No . (I have to confess I deleted some stuff from the builddir before) . >Normally, incremental builds work fine, but they are not 100% proof. In >particular, "make reconfigure" can cause situations that an incremental build >>cannot properly resolve. (Thi

RE: broken dependencies when doing make all ?

>Have you tried doing a "make clean" to see if it resolves the issue? I did an “rm -rf” and full rebuild 😊 !

RE: clang Memory sanitizer (msan) and OpenJDK

out of this one https://bugs.openjdk.org/browse/JDK-8356285 . (sometimes the HS codebase seem to does things that are not liked by MSAN ; maybe the JDK native libs are easier to support for MSAN ) Best regards, Matthias From: Magnus Ihse Bursie Sent: Thursday, 19 June 2025 17:07 To: Baesken, Matthias

hotspot jtreg tests take WARNING_CFLAGS_JDK_CONLY flags

When trying the GCC static analyzer (-fanalyzer flag) diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4 index e80d9a98957..9d1ae60047b 100644 --- a/make/autoconf/flags-cflags.m4 +++ b/make/autoconf/flags-cflags.m4 @@ -610,7 +610,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],

malloc/calloc return value NULL check

Hi, when playing around with the GCC static analyzer ( https://developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12-compiler ) I noticed a lot of complaints about missing NULL checks of malloc/calloc return values in the code base. While we check these return values fo

RE: malloc/calloc return value NULL check

To: Baesken, Matthias Cc: build-dev@openjdk.org Subject: Re: malloc/calloc return value NULL check Absolutely, yes. The larger the allocated size, the more important. Linux kernel, by default, only protects a small area against NULL accesses; depending on distro, 4KB or 64 (?) KB. And the JVM,