On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/Red
When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
flag --enable-ubsan), in a lot of jfr related tests like
compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr
this oob error can be seen :
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote:
> Currently we run into some alignment related issues when building with
> '--enable-ubsan' . Those errors already occur in the build. Fixing them might
> take some time and maybe also some discussion if it is worth the effo
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote:
> Currently we run into some alignment related issues when building with
> '--enable-ubsan' . Those errors already occur in the build. Fixing them might
> take some time and maybe also some discussion if it is worth the effo
Currently we run into some alignment related issues when building with
'--enable-ubsan' . Those errors already occur in the build. Fixing them might
take some time and maybe also some discussion if it is worth the effort ,
So for now the alignment related checks should be disabled to get the
On Wed, 20 Mar 2024 05:44:48 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 11 commits:
>
> - Merge branch
On Fri, 12 Apr 2024 12:26:06 GMT, Magnus Ihse Bursie wrote:
> Unfortunately, after
> [JDK-8329704](https://bugs.openjdk.org/browse/JDK-8329704) AIX fails to
> build. The reason is that libjli is specially treated on AIX, and built like
> a static library. I tried to compensate for this (and
On Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote:
> On AIX, we need a static libjli, since the linker cannot find other libraries
> (like libjvm.so and libjava.so) using a relative path, as on other platforms.
>
> However, for reasons unclear, we still build a dynamic libjli.so on
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLi
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLi
After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the
AIX build into this failure :
/opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Tue, 12 Mar 2024 15:27:29 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Tue, 12 Mar 2024 16:02:41 GMT, Matthias Baesken wrote:
> > Please re-test.
>
> Hi Magnus, thanks for the adjustments. I reenabled your patch in our
> build/test queue .
Builds and test results on AIX (product and fastdebug) are fine with the latest
version of the PR .
--
On Tue, 12 Mar 2024 15:24:21 GMT, Magnus Ihse Bursie wrote:
> Please re-test.
Hi Magnus, thanks for the adjustments. I reenabled your patch in our
build/test queue .
-
PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1992009593
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Fri, 23 Feb 2024 12:33:48 GMT, Magnus Ihse Bursie wrote:
> > We had the PR in our SAP internal build/test queue, so issues seen with it.
>
> What issues did you see? Or was that a typo for "no issues"?
Sorry Magnus, tests were fine no issues were observed.
-
PR Comment:
On Fri, 23 Feb 2024 11:01:47 GMT, Magnus Ihse Bursie wrote:
> Just to confirm: this PR passes tier 1-5.
We had the PR in our SAP internal build/test queue, so issues seen with it.
-
PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961232277
On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote:
>>> I hope finally the AIX part of this PR is done.
>>
>> Thanks for the AIX related effort ; I put it again into our internal
>> build/test queue.
>
>>
>> Thanks for the AIX related effort ;
On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote:
>
> Thanks for the AIX related effort ; I put it again into our internal
> build/test queue.
With the latest commit the build again fails on AIX with this error
/jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl
On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote:
> I hope finally the AIX part of this PR is done.
Thanks for the AIX related effort ; I put it again into our internal build/test
queue.
-
PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669
On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote:
> It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have
> not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef
> _ALLBSD_SOURCE`, which I presume is not defined on AIX.
>
> I recommend
On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote:
> Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on
> AIX to 32-Bit. _LARGE_FILES really does not help in this case!
Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64
variant needs to
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/Buffere
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull requ
On Thu, 1 Feb 2024 09:04:47 GMT, Magnus Ihse Bursie wrote:
> I added a compile-time check that hotspot on AIX is indeed compiled with
> _LARGE_FILES.
>
> @MBaesken Are you happy with this PR now?
Thanks for adding this, I approved the PR .
-
PR Comment:
On Tue, 30 Jan 2024 12:25:47 GMT, Magnus Ihse Bursie wrote:
>> In the same spirit as
>> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
>> the AIX-specific code in hotspot so it uses the well-defined posix ``
>> functions, instead of `64`. By setting the define
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with
On Wed, 31 Jan 2024 08:49:58 GMT, Magnus Ihse Bursie wrote:
> I suspect this worry of yours were more directed at the change for the JDK
Yes it is more a general worry, not especially related to Hotspot.
We could also add some kind of check (e.g. static assert or configure check)
to address
On Mon, 29 Jan 2024 13:13:44 GMT, Matthias Baesken wrote:
>> In the same spirit as
>> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
>> the AIX-specific code in hotspot so it uses the well-defined posix ``
>> functions, instead of `64
On Tue, 30 Jan 2024 13:54:45 GMT, Magnus Ihse Bursie wrote:
> I'd appreciate if you could take the latest version for a spin, particularly
> a debug build...
Yes we pick up the latest version of the PR in a couple of hours for the
build+'lots of tests' (and this includes a fastdebug too).
On Tue, 30 Jan 2024 13:02:53 GMT, Magnus Ihse Bursie wrote:
> @MBaesken You gotta be kidding me... They just put in a `#define open open64`
> in a convenient place?
>
> But why do only slowdebug fail? Weird.
Yes there is a nice define in the AIX header
ifdef _LARGE_FILES
#define open
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
AIX fastdebug build fails with the patch, build error is
On Mon, 29 Jan 2024 13:54:35 GMT, Joachim Kern wrote:
> Why not CFLAGS_OS_DEF_JVM="-DAIX -D_LARGE_FILES" as the equivalent on Linux
I think this PR is intended to be just about the JDK libs, not JVM compilation.
-
PR Review Comment:
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
I put it into our build/test patch list to see how it
On Mon, 29 Jan 2024 11:44:34 GMT, Magnus Ihse Bursie wrote:
> In the same spirit as
> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
> the AIX-specific code in hotspot so it uses the well-defined posix ``
> functions, instead of `64`. By setting the define
On Mon, 22 Jan 2024 12:19:25 GMT, Sam James wrote:
> Could someone run the other commands again for older branches for me as well?
> I don't have access.
Will look into 17 as well. Might make sense to have some other minor backports
to jdk17u-dev before, to make the backport easier (maybe
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts
On Fri, 12 Jan 2024 13:32:28 GMT, Julian Waters wrote:
>As I mentioned above, the autoconf inserting of those compiler flags can be
>disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly empty
>values. It's also a workaround, but is slightly less hacky than filtering out
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote:
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
> -std=gnu++11 by default to CXX in the configure process .
> This is not really wanted so better remove / filter out those -std* flags
> added by autoc
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out those -std* flags
>>
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out any -std* flags
>> a
On Fri, 12 Jan 2024 06:32:34 GMT, Kim Barrett wrote:
> > Thanks! We may switch to clang 14 on MacOS at some point of time, but it's
> > better to have that disentangled. Some people build JDK 11 and 23 on the
> > same machine and that is easier if they don't have to switch Xcode.
>
> I think
On Thu, 11 Jan 2024 13:54:01 GMT, Christoph Langer wrote:
> Makes sense. It's the same pattern.
I adjusted the second GREP too and removed the` if test` .
-
PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1887318284
ilar for some time for CFLAGS and CXXFLAGS ( see
> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that
> dates back to JDK 9.
>
> See the discussion about this issue :
> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html
Matthias Baesken has updated the pu
ilar for some time for CFLAGS and CXXFLAGS ( see
> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that
> dates back to JDK 9.
>
> See the discussion about this issue :
> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html
Matthias Baesken has updated the pu
On Thu, 11 Jan 2024 11:19:01 GMT, Magnus Ihse Bursie wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adjust GREP call
>
> make/autoconf/toolchain.m4 line 395:
>
>> 393:
On Thu, 11 Jan 2024 11:06:02 GMT, Christoph Langer wrote:
> > Strange, I noticed that for some reason the
> > UTIL_GET_NON_MATCHING_VALUES(cxx_filtered, $CXX, -std=c++11 -std=gnu++11)
> > seems not to remove the flags as expected, did I misinterpret how
> > UTIL_GET_NON_MATCHING_VALUES works
ilar for some time for CFLAGS and CXXFLAGS ( see
> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that
> dates back to JDK 9.
>
> See the discussion about this issue :
> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html
Matthias Baesken has updated the pu
On Wed, 10 Jan 2024 13:11:38 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary -std=c++17 option in
On Tue, 9 Jan 2024 17:03:43 GMT, Julian Waters wrote:
> Rather than filtering through the added flags like this, is it possible to
> figure out why macOS trips the C++11 heuristic and fix the problem there?
That might be a bit tricky, because on my macOS test machine, with a self
compiled
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote:
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
> -std=gnu++11 by default to CXX in the configure process .
> This is not really wanted so better remove / filter out any -std* flags added
> by autoconf
It was observed, that autoconf 2.72 added on macOS x86_64 the flag -std=gnu++11
by default to CXX in the configure process .
This is not really wanted so better remove / filter out any -std* flags added
by autoconf from CC/CXX .
Seems we have something similar for some time for CFLAGS and
On Fri, 3 Nov 2023 14:46:39 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>
>> One solution is to
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote:
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
This pull request has now been integrated.
Changeset: b9983c72
Author:Matthias Baesken
URL:
On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken wrote:
>> Increase javacserver connection timeout values and max retry attempts for
>> better make stability on some slower machines.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust WAIT_BETWEEN_CONNECT_AT
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote:
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
I adjusted the WAIT_BETWEEN_CONNECT_ATTEMPTS; Let's how this works.
-
PR Comment:
Increase javacserver connection timeout values and max retry attempts for
better make stability on some slower machines.
-
Commit messages:
- JDK-8318961
Changes: https://git.openjdk.org/jdk/pull/16397/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=16397=00
Issue:
On Wed, 27 Sep 2023 08:18:45 GMT, Matthias Baesken wrote:
> Running jtreg tests with make test, for example
> make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX
> without setting the number of JOBS manually.
> We get this error message:
> Error
On Thu, 28 Sep 2023 12:57:07 GMT, Matthias Baesken wrote:
>> Running jtreg tests with make test, for example
>> make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX
>> without setting the number of JOBS manually.
>> We get this error message:
ded ints, so
> better print ints in the makefile by using %d .
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Add 0.5 to avoid rounding issues
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15941/files
- new:
On Wed, 27 Sep 2023 17:09:04 GMT, Erik Joelsson wrote:
> To work around this, perhaps add 0.5 to c before converting to int?
Hi Erik, sure we can do so , I adjusted the change.
-
PR Comment: https://git.openjdk.org/jdk/pull/15941#issuecomment-1739103028
On Wed, 27 Sep 2023 12:15:18 GMT, Magnus Ihse Bursie wrote:
> Looks good. Have you verified that this works with nawk as well as old gawk
> versions?
On AIX I have both nawk and gawk on the machine and both work with the change.
On Linux I have just gawk (more recent one) and this works too.
Running jtreg tests with make test, for example
make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX without
setting the number of JOBS manually.
We get this error message:
Error: Bad use of -concurrency
Log of cmdargs shows :
-vmoption:-Xmx768m
-agentvm
On Mon, 4 Sep 2023 07:40:11 GMT, Matthias Baesken wrote:
>> After looking at the build results of a jdk22 build on RHEL 8.4 Linux
>> ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0
>> devkit we observed those unwanted paths in libsplashscreen
On Fri, 1 Sep 2023 11:02:36 GMT, Matthias Baesken wrote:
> After looking at the build results of a jdk22 build on RHEL 8.4 Linux ppc64le
> that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0
> devkit we observed those unwanted paths in libsplashscreen.so .
> See t
On Mon, 4 Sep 2023 07:40:11 GMT, Matthias Baesken wrote:
>> After looking at the build results of a jdk22 build on RHEL 8.4 Linux
>> ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0
>> devkit we observed those unwanted paths in libsplashscreen
On Fri, 1 Sep 2023 16:55:21 GMT, Erik Joelsson wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> check for SYSROOT and xlib-setting
>
> make/autoconf/lib-x11.m4 line 38:
>
>&
vkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6
> (0x7fffa38e)
>. . .
>
> These paths were introduced by the '-R' setting, but it seems to be highly
> dependent on the environment. But the '-R' setting sho
vkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6
> (0x7fffa38e)
>. . .
>
> These paths were introduced by the '-R' setting, but it seems to be highly
> dependent on the environment. But the '-R' setting sho
On Fri, 1 Sep 2023 12:54:45 GMT, Erik Joelsson wrote:
>> After looking at the build results of a jdk22 build on RHEL 8.4 Linux
>> ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0
>> devkit we observed those unwanted paths in libsplashscreen.so .
>> See those objdump
After looking at the build results of a jdk22 build on RHEL 8.4 Linux ppc64le
that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0
devkit we observed those unwanted paths in libsplashscreen.so .
See those objdump and ldd output :
objdump -x ./lib/libsplashscreen.so | grep PATH
On Mon, 28 Aug 2023 02:26:30 GMT, David Holmes wrote:
> Sorry but looking at the hotspot part of this I do not like the code in
> jvm.cpp at all - it is far too messy. I expected to see a simple interface to
> os::dlopen which then handles all the platform specific issues.
>
> I'm also
On Wed, 23 Aug 2023 12:26:36 GMT, Martin Doerr wrote:
> Please check windows-aarch64 build error: unresolved external symbol
> dlopen_ext
Hi Martin, thanks ! I did a small adjustment, now the windows aarch64 build
works.
-
PR Comment:
Cache on AIX ( see
> LoadedLibraries::reload() , see also
> https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and
> sometimes reports outdated information
>
> Offer an interface (e.g. jvm.cpp) to support
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote:
> Currently there is a number of functionality that would be interesting to
> have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event Na
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote:
> Currently there is a number of functionality that would be interesting to
> have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event Na
Currently there is a number of functionality that would be interesting to have
for shared lib load operations in the JDK C code.
Some examples :
Events::log_dll_message for hs-err files reporting
JFR event NativeLibraryLoad
There is the need to update the shared lib Cache on AIX ( see
On Wed, 9 Aug 2023 15:26:05 GMT, Andreas Steiner wrote:
>> On AIX we need the -X64 option for NM in the build. The handling is
>> equivalent to the other used tools flags like AR.
>> This change will replace the quick fix done in
>> https://bugs.openjdk.org/browse/JDK-8312466.
>
> Andreas
On Tue, 25 Jul 2023 12:00:56 GMT, Matthias Baesken wrote:
> In case of issues in the configure step, we run into error messages like this
> :
>
> configure: Current directory is /openjdk/jdk_4/build_mymachine.
> configure: Since this is not the source root, config
On Wed, 26 Jul 2023 07:21:13 GMT, Matthias Baesken wrote:
>> In case of issues in the configure step, we run into error messages like
>> this :
>>
>> configure: Current directory is /openjdk/jdk_4/build_mymachine.
>> configure: Since this is not the sour
On Fri, 4 Aug 2023 11:17:43 GMT, Andreas Steiner wrote:
>> On AIX we need the -X64 option for NM in the build. The handling is
>> equivalent to the other used tools flags like AR.
>> This change will replace the quick fix done in
>> https://bugs.openjdk.org/browse/JDK-8312466.
>
> Andreas
On Tue, 1 Aug 2023 12:50:47 GMT, Andreas Steiner wrote:
>> Add the default include location(/opt/freeware/include/) for cups on AIX.
>> With this set the additional configure parameter --with-cups-include can be
>> removed, which was needed on AIX.
>
> Andreas Steiner has updated the pull
On Wed, 26 Jul 2023 07:21:13 GMT, Matthias Baesken wrote:
>> In case of issues in the configure step, we run into error messages like
>> this :
>>
>> configure: Current directory is /openjdk/jdk_4/build_mymachine.
>> configure: Since this is not the sour
On Mon, 31 Jul 2023 18:17:03 GMT, Aleksey Shipilev wrote:
> Some GHA runs are now running into configuration problems after runner
> update. We need to bump the GCC versions to unbreak them.
>
> Additional testing:
> - [x] GHA
Marked as reviewed by mbaesken (Reviewer).
-
PR
On Tue, 1 Aug 2023 12:46:17 GMT, Andreas Steiner wrote:
>> Add the default include location(/opt/freeware/include/) for cups on AIX.
>> With this set the additional configure parameter --with-cups-include can be
>> removed, which was needed on AIX.
>
> Andreas Steiner has updated the pull
On Tue, 1 Aug 2023 07:28:02 GMT, Andreas Steiner wrote:
> Add the default include location(/opt/freeware/include/) for cups on AIX.
> With this set the additional configure parameter --with-cups-include can be
> removed, which was needed on AIX.
Looks reasonable, but you would overwrite the
On Wed, 26 Jul 2023 10:29:25 GMT, Andreas Steiner wrote:
>> On AIX the 'nm' needs -X64 option.
>
> Andreas Steiner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> correction of comment
There might be room for improvement for the general
On Wed, 26 Jul 2023 07:21:13 GMT, Matthias Baesken wrote:
>> In case of issues in the configure step, we run into error messages like
>> this :
>>
>> configure: Current directory is /openjdk/jdk_4/build_mymachine.
>> configure: Since this is not the sour
On Wed, 26 Jul 2023 14:15:25 GMT, Christoph Langer wrote:
> OTOH, this cleanup could be done in another PR. For now, the code as it is
> would be ok, too.
I agree, let's do the flags / macro adjustment in another issue. Andreas, I can
open one for you if you want.
-
PR Comment:
On Wed, 26 Jul 2023 12:10:51 GMT, David Holmes wrote:
> I don't think this is the right place to make this change. Shouldn't it be
> handled at configure time in ./autoconf/toolchain.m4 ? There is also a
> BUILD_NM variable that will not be fixed by the proposed change.
Currently all needed
On Wed, 26 Jul 2023 10:29:25 GMT, Andreas Steiner wrote:
>> On AIX the 'nm' needs -X64 option.
>
> Andreas Steiner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> correction of comment
Marked as reviewed by mbaesken (Reviewer).
On Wed, 26 Jul 2023 08:10:26 GMT, Julian Waters wrote:
> I am fairly certain there is a better spot for this, but I cannot remember
> where at the moment. Is this for JvmMapfile.gmk where we dump the symbols of
> object files, or for something else?
It is needed for the
On Wed, 26 Jul 2023 07:52:44 GMT, Andreas Steiner wrote:
> On AIX the 'nm' needs -X64 option.
Hi Andreas, thanks for addressing this.
Should it be 'needs' instead of 'need' in the comment you added ?
Btw did you look at the naming of the mangled symbols we check for
On Tue, 25 Jul 2023 12:00:56 GMT, Matthias Baesken wrote:
> In case of issues in the configure step, we run into error messages like this
> :
>
> configure: Current directory is /openjdk/jdk_4/build_mymachine.
> configure: Since this is not the source root, config
but the non-existance of spec.gmk does not mean we are not in a build
> directory.
> We could additionally check for e.g. $OUTPUTDIR/configure-support/config.log
> or something related to check if it is a build directory .
Matthias Baesken has updated the pull request incrementally with o
1 - 100 of 179 matches
Mail list logo
