Hello
After compiling and packaging in the local environment, I encountered a
crash when using the packaged JDK, and there are no relevant logs. Is there
any good method to analyze the cause of the crash?
Thanks
On 7/08/2024 4:42 am, Elazar Leibovich wrote:
Thanks,
I did follow the readme, but could not find any commentary about the
build environment or the required compilers.
There is a tiny bit of info there but I think it is out-of-date:
Linux X86 (32-bit) and X64 (64-bit) Fedora 9 gcc 4.3
Mac OS
On Tue, 6 Aug 2024 18:58:42 GMT, Magnus Ihse Bursie wrote:
> > No, it's not when building libjvm.a. It's when linking the final elf
> > executable using libjvm.a (or libnet.a, etc) that's created with ld -r or
> > objcopy. During the final elf executable linking time, user could include
> > ad
On Tue, 6 Aug 2024 22:04:36 GMT, David Holmes wrote:
>> A trivial fix to remove EA from the JDK 23 version string with first RC
>> promotion.
>
> Good
@dholmes-ora - Thanks for the lightning fast review! I just changed the bug from
confidential so we'll see when the bot wakes up...
---
On Tue, 6 Aug 2024 22:02:33 GMT, Daniel D. Daugherty wrote:
> A trivial fix to remove EA from the JDK 23 version string with first RC
> promotion.
This pull request has now been integrated.
Changeset: 6f582f4e
Author:Daniel D. Daugherty
URL:
https://git.openjdk.org/jdk/commit/6f582
On Tue, 6 Aug 2024 22:02:33 GMT, Daniel D. Daugherty wrote:
> A trivial fix to remove EA from the JDK 23 version string with first RC
> promotion.
Good
-
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20481#pullrequestreview-314019
A trivial fix to remove EA from the JDK 23 version string with first RC
promotion.
-
Commit messages:
- 8337831: Remove EA from the JDK 23 version string with first RC promotion
Changes: https://git.openjdk.org/jdk/pull/20481/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr
On Tue, 6 Aug 2024 17:07:55 GMT, Jiangli Zhou wrote:
> No, it's not when building libjvm.a. It's when linking the final elf
> executable using libjvm.a (or libnet.a, etc) that's created with ld -r or
> objcopy. During the final elf executable linking time, user could include
> additional desir
Thanks,
I did follow the readme, but could not find any commentary about the build
environment or the required compilers.
Even less information was on Mac OS X, where the autoconf files seems not
to be updated, and as a result arm was chosen instead of aarch64.
If you can point me to a specific se
On 2024-08-06 20:33, Elazar Leibovich wrote:
Thanks,
I still fail to understand how JDK8u developers are building the project.
Setting up a build environment for jdk8 is unfortunately not a trivial
task. The build readme can be of some use:
https://github.com/openjdk/jdk8u-dev/blob/master/do
Thanks,
I still fail to understand how JDK8u developers are building the project.
Is there a docker file specifying the build environment? What's the
recommended way of doing that?
Removing the register keyword, plus disabling an overflow warning in a
specific test with pragma did the trick for me,
On Tue, 6 Aug 2024 13:26:00 GMT, Magnus Ihse Bursie wrote:
> But why and how do you specify `-Wl,--icf=safe` when building libjvm.a? That
> is not part of the linker flags in the JDK build mainline. I have not
> encountered these problems when trying to link with lld.
No, it's not when **build
Hi Kurt,
Did you manage to resolve this issue?
/Magnus
On 2024-07-10 23:52, Kurt Stine wrote:
Hi Everyone,
I’m running into an issue when trying to cross-compile the latest
jdk8u for powerpc (32 bit).
I am cross-compiling from x86_64 with Azul Zulu JDK 7 as my boot JDK.
Whenever I try an
Hi Elazar,
I see that you never got any replies here. I suggest that you re-ask
your question on the jdk8u mailing list instead (cc'd).
/Magnus
On 2024-07-19 16:20, Elazar Leibovich wrote:
When trying to compile the latest jdk8u on linux I get failures over
warnings with the register keyword
On Mon, 5 Aug 2024 18:34:01 GMT, Leonid Mesnik wrote:
>> There jtreg tests have several additional problemlists
>> ProblemList-Xcomp.txt
>> ProblemList-generational-zgc.txt
>> ProblemList-zgc.txt
>> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it
>> makes sense to treat
On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou wrote:
> Please review this PR that strips the `.llvm_addrsig` section from JDK and
> hotspot `.a` static libraries when building with clang. Please see
> https://bugs.openjdk.org/browse/JDK-8336849 description for details.
But why and how do you
On Mon, 5 Aug 2024 18:37:24 GMT, Leonid Mesnik wrote:
>> make/RunTests.gmk line 849:
>>
>>> 847:
>>> 848: ifneq ($$(findstring -XX:+UseZGC, $$(JTREG_ALL_OPTIONS)), )
>>> 849: ifneq ($$(findstring -XX:-ZGenerational, $$(JTREG_ALL_OPTIONS)), )
>>
>> Is this the only way that zgc can be run
On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt wrote:
> On MacOS, files may have extended attributes attached. These attributes are
> copied together with the files. To prevent issues during further processing,
> the extended attributes of the copies must be removed. This action was
> implemen
18 matches
Mail list logo
