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
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
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?
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
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
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
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
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
Vote: yes
Best regards, Matthias
>I hereby nominate Christoph Langer (clanger) to Membership in the Build Group.
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
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
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
>>
>> 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
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.
>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
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
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,
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
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
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
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
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
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)
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
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
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
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
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
28 matches
Mail list logo
