Re: RFR: 8257056: Submit workflow should apt-get update to avoid package installation errors

On Wed, 25 Nov 2020 08:56:33 GMT, Aleksey Shipilev wrote: > For example, current jobs fail with: > > Get:13 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 libxtst-dev > amd64 2:1.2.3-1 [15.2 kB] > E: Failed to fetch > http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/libasou

Re: RFR: 8270117: Broken jtreg link in "Building the JDK" page

On Mon, 12 Jul 2021 13:17:18 GMT, Magnus Ihse Bursie wrote: > Paraphrased description from the bug report: > > The "Building the JDK" page has a jtreg download link pointing to > > but that gets a 404. I bel

Re: RFR: 8270117: Broken jtreg link in "Building the JDK" page [v2]

On Mon, 12 Jul 2021 17:41:27 GMT, Magnus Ihse Bursie wrote: >> Paraphrased description from the bug report: >> >> The "Building the JDK" page has a jtreg download link pointing to >> >> but that gets a 404.

RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info

Hi! Please review this tiny patch which removes the special casing of `--with-native-debug-symbols=external` for the static libs build. I don't see why this is needed. If no debug symbols are wanted `--with-native-debug-symbols=none` can be used to achieve the same effect. Therefore, I propose

Re: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info

On Thu, 22 Jul 2021 17:38:28 GMT, Mikael Vidstedt wrote: >> Hi! >> >> Please review this tiny patch which removes the special casing of >> `--with-native-debug-symbols=external` for the static libs build. I don't >> see why this is needed. If no debug symbols are wanted >> `--with-native-debu

RFR: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790

Please review this simple build fix to correct the type done in JDK-8255790. After the patch correct external library is added to the `libfontmanager.so` link command when building with `--with-harfbuzz=system`. Thoughts? - Commit messages: - 8272332: --with-harfbuzz=system doesn'

Re: RFR: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790

On Wed, 11 Aug 2021 18:21:14 GMT, Phil Race wrote: >> Please review this simple build fix to correct the typo done in JDK-8255790. >> After the patch correct external library is added to the `libfontmanager.so` >> link command when building with `--with-harfbuzz=system`. >> >> Thoughts? > > Ma

Integrated: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790

On Wed, 11 Aug 2021 17:58:04 GMT, Severin Gehwolf wrote: > Please review this simple build fix to correct the typo done in JDK-8255790. > After the patch correct external library is added to the `libfontmanager.so` > link command when building with `--with-harfbuzz=system`. >

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". > This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We > need to see if moving the libjvm.so to a proper location breaks anything. > > Ad

Withdrawn: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info

On Thu, 22 Jul 2021 16:43:26 GMT, Severin Gehwolf wrote: > Hi! > > Please review this tiny patch which removes the special casing of > `--with-native-debug-symbols=external` for the static libs build. I don't see > why this is needed. If no debug symbols are wanted &g

Re: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info

On Thu, 22 Jul 2021 16:43:26 GMT, Severin Gehwolf wrote: > Hi! > > Please review this tiny patch which removes the special casing of > `--with-native-debug-symbols=external` for the static libs build. I don't see > why this is needed. If no debug symbols are wanted &g

Re: RFR: 8276746: Add section on reproducible builds in building.md

On Fri, 5 Nov 2021 16:30:26 GMT, Magnus Ihse Bursie wrote: > Reproducible builds are all the vogue. The JDK has been making great strides > in getting there, but still has some way to go. However, to get as close as > possible, some special configuration is needed. > > This has been "tribal k

Re: [Ping?] [8u] RFR: 8210283: Support git as an SCM alternative in the build

On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote: > Hi, > > Please review this adaptation of the corresponding JDK 11 patch. The > JDK 11u patch didn't apply because the build system is widely different > between these two releases. > > The main difference i

Re: Heads up: planned Harfbuzz update in jdk11u-dev

On Fri, 2022-01-14 at 09:19 +, Baesken, Matthias wrote: > For one of the next jdk11 updates, an update to a more recent harfbuzz > version is planned. > This has been done already in jdk/jdk some time ago, and was backported > recently to jdk13, > please see the harfbuzz 2.7.2 / 2.8.0 related

Re: [Ping2?] [8u] RFR: 8210283: Support git as an SCM alternative in the build

On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote: > On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote: > > Hi, > > > > Please review this adaptation of the corresponding JDK 11 patch. The > > JDK 11u patch didn't apply because the build system is wi

Re: [Ping2?] [8u] RFR: 8210283: Support git as an SCM alternative in the build

Hi Andrew, On Wed, 2022-02-09 at 03:54 +, Andrew Hughes wrote: > On 20:33 Thu 03 Feb , Severin Gehwolf wrote: > > On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote: > > > On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote: > > > > Hi, >

Re: [Ping2?] [8u] RFR: 8210283: Support git as an SCM alternative in the build

On Tue, 2022-02-15 at 02:53 +, Andrew Hughes wrote: > On 14:09 Thu 10 Feb , Severin Gehwolf wrote: > > > > Latest webrev: > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/02/webrev/ > > > > OK? > > > > Thanks, > > Severin

Re: RFR: 8282567: Improve source-date handling in build system

On Wed, 2 Mar 2022 16:54:21 GMT, Magnus Ihse Bursie wrote: > To clarify, the end effect of these changes is that building OpenJDK will > basically be compliant with the method of just setting SOURCE_DATE_EPOCH. > (The caveat is that it must be set at configure time, not build time.) So > > ```

Re: RFR: 8282567: Improve source-date handling in build system [v4]

On Fri, 4 Mar 2022 23:43:12 GMT, Magnus Ihse Bursie wrote: > As for RPM builds (by whom?) We, Red Hat, build OpenJDK in Fedora and RHEL via `rpmbuild` :) > suddenly being build with --enable-reproducible-build, I would not think it > is a matter of concern. For linux, the only real difference

Re: RFR: 8282567: Improve source-date handling in build system [v5]

On Sat, 5 Mar 2022 08:57:45 GMT, Magnus Ihse Bursie wrote: >> When doing reproducible builds, controlling the build time is imperative. To >> make this as easy as possible, some changes are needed in the build system. >> >> * If source-date is set to anything other than "updated" (meaning that

Re: RFR: 8286105: SourceRevision.gmk should respect GIT variable

On Wed, 4 May 2022 03:06:44 GMT, Yasumasa Suenaga wrote: > We can specify `git` binary via `GIT` in configure script, but it does not > affect in SourceRevision.gmk . LGTM - Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8526

RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't

`make test TEST="gtest:https://git.openjdk.java.net/jdk/pull/8605/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8605&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286430 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pul

Re: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't

On Mon, 9 May 2022 18:39:28 GMT, Severin Gehwolf wrote: > `make test TEST="gtest: `1.10.0`. It expects `suites` to be present in the google test output whereas > the OpenJDK build infra code expects `cases`. I'm not sure when/if that > changed, but here is a proposed

Re: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't [v2]

> `make test TEST="gtest: `1.10.0`. It expects `suites` to be present in the google test output whereas > the OpenJDK build infra code expects `cases`. I'm not sure when/if that > changed, but here is a proposed fix. > > Thoughts? Severin Gehwolf has updated the pull r

Re: RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't [v2]

On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote: >> `make test TEST="gtest:> `1.10.0`. It expects `suites` to be present in the google test output >> whereas the OpenJDK build infra code expects `cases`. I'm not sure when/if >> that changed, but here is

Integrated: 8286430: make test TEST="gtest:" exits with error when it shouldn't

On Mon, 9 May 2022 18:39:28 GMT, Severin Gehwolf wrote: > `make test TEST="gtest: `1.10.0`. It expects `suites` to be present in the google test output whereas > the OpenJDK build infra code expects `cases`. I'm not sure when/if that > changed, but here is a proposed fix. &

Re: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya wrote: > At default configuration, SOURCE_DATE_EPOCH is exported as environment > variable in SetupReproducibleBuild. Then, gcc is affected of > SOURCE_DATE_EPOCH environment variable. This value is used only to set > SOURCE_DATE_ISO_8601 (excep

Re: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default

On Mon, 13 Jun 2022 07:14:15 GMT, Magnus Ihse Bursie wrote: >> At default configuration, SOURCE_DATE_EPOCH is exported as environment >> variable in SetupReproducibleBuild. Then, gcc is affected of >> SOURCE_DATE_EPOCH environment variable. This value is used only to set >> SOURCE_DATE_ISO_860

Re: zero build slow

Hi Thomas, On Wed, 2017-11-22 at 17:26 +0100, Thomas Stüfe wrote: > Hi guys, > > thanks for your help. > > I think the reason is the combination of zero+slowdebug and the fact that > we run our own binaries during build (at least this is true for jmod). > > I am building on Ubuntu 16.4, "normal

Re: [PATCH] Freetype Directory Bug On zLinux

Hi, On Mon, 2018-01-15 at 20:21 +0100, John Paul Adrian Glaubitz wrote: > Hi Adam! > > On 01/15/2018 06:15 PM, Adam Farley8 wrote: > > > Which I would expect to cover your case, unless there is a > > > mismatch > > > between s390 and s390x here. Is your OPENJDK_TARGET_CPU set to > > > s390 or > >

Re: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf

On Thu, 2018-01-18 at 14:28 +0100, 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 Ope

RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

Hi, Could I please get a review for this rather small patch which originally occurred for us on JDK 8 (Fedora) which recently switched to building with "-Wl,-z,defs" linker flags. The result was a build failure, due to unresolved symbols. Indeed libfontmanager.so should have -lawt_headless in the

Re: RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

filter is for -Xlinker. Now with JDK 11 it's the other way around. With that being said, this discussion is a moot point if we can remove this. Thanks, Severin > /Erik > > On 2018-01-26 08:10, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review fo

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

ebrev shortly. Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on platforms that need it? solaris, linux, aix should already be fine without filtering. Thanks, Severin > So we already use -lawt_headless on solaris and aix, then I really can't > see a reason

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

On Fri, 2018-01-26 at 09:18 -0800, Phil Race wrote: > > On 01/26/2018 09:02 AM, Severin Gehwolf wrote: > > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > > platforms that need it? solaris, linux, aix should already be fine > > without filteri

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

ined dynamic_lookup, \ > > LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > > -LIBS_linux := -lc, \ > > +LIBS_linux := -lawt_headless -lc, \ > > LIBS_solaris := -lawt_headless -lc, \ > >

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

review! I'll run this through the new submit repo and - barring unforeseen circumstances - will push it once approved. Cheers, Severin > On 2018-01-29 01:39, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev which removes the linker flags filtering. Linking with &

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

7;t see any reason this would need a sponsor, jdk/jdk should > be open. > > /Erik > > > On 2018-01-29 01:39, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev which removes the linker flags filtering. Linking with > > the awt lib is being kept. ldd con

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

email - so far, though. Cheers, Severin > -phil. > > On 01/29/2018 10:53 AM, Severin Gehwolf wrote: > > Hi Phil, > > > > Are you OK with the latest webrev as well? > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ > > > > Thanks, &

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

On Tue, 2018-01-30 at 08:36 -0800, Erik Joelsson wrote: > I found your job and it's all successful. Something is up with the > service though. I'm pinging the relevant people here. Yes, indeed: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000622.html Thanks, Erik! Cheers, Severin

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

lient/ or http://hg.openjdk.java.net/jdk/jdk/ Thanks, Severin > /Erik > > > On 2018-01-30 00:42, Severin Gehwolf wrote: > > On Mon, 2018-01-29 at 12:09 -0800, Phil Race wrote: > > > It looks OK but have you tried running it through the new build > > > system >

Re: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library

An exploded build is fine but the images build (what we ship) is > broken. Exploded build works fine for me too. Which linux systems are those? > I think I'll need to back this out. OK. > A good thing it was pushed to client .. Yes. Thanks, Severin > -phil. > > On 01/3

RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Hi, Could somebody please review this build fix for libfontmanager.so. The issue for us is that with some LDFLAGS the build breaks as described in bug JDK-8196218. However, we cannot link to a providing library at build-time since we don't know which one it should be: libawt_headless or libawt_xaw

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

New webrev at: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 Could someone from awt-dev have a look at this too? Thanks! Cheers, Severin > /Erik > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > On 2018-04-09 06:39, Severin Ge

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

On Mon, 2018-04-09 at 15:39 +0200, Severin Gehwolf wrote: > Hi, > > Could somebody please review this build fix for libfontmanager.so. The > issue for us is that with some LDFLAGS the build breaks as described in > bug JDK-8196218. However, we cannot link to a providing library

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

that bug is private :( Thanks, Severin > On 10/04/2018 09:34, Erik Joelsson wrote: > > Looks good. Thanks! > > > > /Erik > > > > > > On 2018-04-10 04:25, Severin Gehwolf wrote: > > > Hi Erik, > > > > > > On Mon, 2018-04-09 at 09:20 -0

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

On Tue, 2018-04-10 at 09:34 -0700, Erik Joelsson wrote: > Looks good. Thanks! Thanks, Erik. Cheers, Severin > /Erik > > > On 2018-04-10 04:25, Severin Gehwolf wrote: > > Hi Erik, > > > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: > > &g

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Hi Magnus, On Tue, 2018-04-10 at 22:57 +0200, Magnus Ihse Bursie wrote: > On 2018-04-10 13:25, Severin Gehwolf wrote: > > Hi Erik, > > > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: > > > Hello Severin, > > > > > > I'm ok with

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

LDFLAGS_aix > setting. I've opened "8201524: [AIX] Don't link libfontmanager against > libawt_headless" [1] for it and I'll send out a new RFR for it soon. > > Regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8201524 > > > On

Re: Invalid use of -m32 on certain targets

On Thu, 2018-04-12 at 18:56 +0200, Magnus Ihse Bursie wrote: > > 12 apr. 2018 kl. 15:49 skrev John Paul Adrian Glaubitz > > : > > > > Hi! > > > > I have been playing around with Zero on new (old) architectures and one > > of them is hppa, which needs some additional work due to its stack growing

Re: Invalid use of -m32 on certain targets

On Fri, 2018-04-13 at 13:17 +0200, Severin Gehwolf wrote: > On Thu, 2018-04-12 at 18:56 +0200, Magnus Ihse Bursie wrote: > > > 12 apr. 2018 kl. 15:49 skrev John Paul Adrian Glaubitz > > > : > > > > > > Hi! > > > > > > I have been pl

8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

Hi, We (Red Hat) have been building Zero on s390 for a while now. In order to do so we needed to have this patch to reduce the maximum heap size setting for big workloads. Otherwise we see this during (JDK 9) builds: ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s3

Re: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

Hi Andrew, On Mon, 2018-04-16 at 09:47 +0100, Andrew Haley wrote: > On 04/13/2018 02:40 PM, Severin Gehwolf wrote: > > ++ /usr/bin/tee > > /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log >

Re: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

Hi Magnus, On Mon, 2018-04-16 at 10:58 +0200, Magnus Ihse Bursie wrote: > On 2018-04-13 15:40, Severin Gehwolf wrote: > > Hi, > > > > We (Red Hat) have been building Zero on s390 for a while now. In order > > to do so we needed to have this patch to reduce the maximu

Re: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

On Mon, 2018-04-16 at 12:01 +0200, Volker Simonis wrote: > On Mon, Apr 16, 2018 at 11:30 AM, Severin Gehwolf wrote: > > Hi Andrew, > > > > On Mon, 2018-04-16 at 09:47 +0100, Andrew Haley wrote: > > > On 04/13/2018 02:40 PM, Severin Gehwolf wrote: > > > >

Re: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

Hi Magnus, On Mon, 2018-04-16 at 10:58 +0200, Magnus Ihse Bursie wrote: > On 2018-04-13 15:40, Severin Gehwolf wrote: > > Hi, > > > > We (Red Hat) have been building Zero on s390 for a while now. In order > > to do so we needed to have this patch to reduce the maximu

RFR: 8201788: Number of make jobs wrong for bootcycle-images target

Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8201788 I'd like to get a fix in for an old discussion which already happened a while ago: http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html The issue is that for bootcycle-images target a recursive call to make is being cal

Re: RFR: 8201788: Number of make jobs wrong for bootcycle-images target

y setting JOBS to a very large number > (like 1000, which is way more than any possible concurrency currently > possible in the build anyway). > > So to summarize, I think the correct solution to the bug is the snippet > above. Alright. How does this webrev loo

Re: RFR: 8201788: Number of make jobs wrong for bootcycle-images target

Hi Erik, On Thu, 2018-04-19 at 09:03 -0700, Erik Joelsson wrote: > Hello, > > On 2018-04-19 08:58, Severin Gehwolf wrote: > > Hi Erik, > > > > Thanks for the review! > > > > On Thu, 2018-04-19 at 08:25 -0700, Erik Joelsson wrote: > > > Hello Se

Re: RFR: 8201788: Number of make jobs wrong for bootcycle-images target

Hi Magnus, On Thu, 2018-04-19 at 20:58 +0200, Magnus Ihse Bursie wrote: > Looks good to me too. Thanks for doing it this way. Thanks for the review, pushed (jdk-submit came back clean). Cheers, Severin > /Magnus > > > 19 apr. 2018 kl. 20:08 skrev Severin Gehwolf : &

[10] RFR: 8202262: libjsig.so not linked with extra linker flags from configure

Hi, Can I please get a review for this JDK 10 only fix, which prevents some extra link flags getting injected to the build of libjsig.so. JDK 11 is not affected. It appears to be a typo. It should be a rather low risk change and helps us reduce downstream carried patches. Bug: https://bugs.openjd

Re: [10] RFR: 8202262: libjsig.so not linked with extra linker flags from configure

On Wed, 2018-04-25 at 08:48 -0700, Erik Joelsson wrote: > The change looks good. You will need to also get approval for pushing to > 10u. Right. Thanks for the review, Erik! Cheers, Severin > /Erik > > > On 2018-04-25 08:44, Severin Gehwolf wrote: > > Hi, > >

[8u] RFR: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

Hi, Could I please get a review for a fix which went into JDK 11 already. It reduces the maximum heap requirement for 32bit builds, which breaks s390 (31 bit) builds: + /usr/lib/jvm/java-openjdk/bin/java -Xms64M -Xmx1100M -XX:ThreadStackSize=768 -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclass

Re: [8u] RFR: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

On Wed, 2018-05-02 at 16:55 +0100, Andrew Hughes wrote: > On 2 May 2018 at 13:43, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review for a fix which went into JDK 11 already. > > It reduces the maximum heap requirement for 32bit builds, which brea

[8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Hi, Could I please get a review of this change for JDK 8u? We are seing build failures due to unresolved symbols when building libfontmanager.so. The build flag to trigger this is to configure with: --with-extra-ldflags="-Wl,-z,defs" Attempting a build of JDK 8 with this fails. This has been fix

Re: JDK 10u and generated-configure.sh

te: > > > Hi Severin, > > > > > > You'll need to file a bug and follow the approval request process. > > > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > -Rob > > > > > >

[10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 (was: Re: JDK 10u and generated-configure.sh)

8202784 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ Anyway, can somebody on the build-team rubber-stamp this, please? Thanks, Severin [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > Thanks, > > -Rob > > On 08/05/18 15:

Re: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495

k > > > On 2018-05-08 07:53, Tim Bell wrote: > > See below- > > > > On 05/08/18 07:39, Severin Gehwolf wrote: > > > Hi, > > > > > > On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: > > > > No, you're correct. The clo

Re: Build failure on Fedora 28

On Tue, 2018-05-08 at 22:42 +0900, Yasumasa Suenaga wrote: > Hi all, > > I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as > following: > > ``` > [ysuenaga@fc28 jdk]$ make images > Building target 'images' in configuration > 'linux-x86_64-normal-server-fastdebug' > gmake[3]:

Re: Build failure on Fedora 28

On Tue, 2018-05-08 at 08:27 -0700, Erik Joelsson wrote: > Hello, > > Your assessment is looks correct so far. At this point, one would have > to start debugging the image to figure out what's wrong with it. Are you > able to run the exploded image in > ./build/linux-x86_64-normal-server-fastdeb

Re: Build failure on Fedora 28

Hi, Note that slowdebug builds work: $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -version openjdk version "11-internal" 2018-09-25 OpenJDK Runtime Environment (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs) OpenJDK 64-Bit Server VM (slowdebug build 11-internal+0

Re: Build failure on Fedora 28

ve anything to think about? The problematic library was indeed libjimage.so. More below. > 2018-05-09 17:22 GMT+09:00 Severin Gehwolf : > > Hi, > > > > Note that slowdebug builds work: > > > > $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -versi

Re: Build failure on Fedora 28

Hi Yasumasa, On Tue, 2018-05-15 at 23:56 +0900, Yasumasa Suenaga wrote: > Hi Severin, > > > Looks like another case of UB in the JDK. This time libjimage.so with a > > signed integer overflow: > > > > https://bugs.openjdk.java.net/browse/JDK-8203223 > > Thanks! > Can you fix pointer increment i

RFR: 8203410: Zero: Disable jfr feature by default

Hi, Currently the jfr (Flight Recorder) feature is being built by default for Zero JVMs. However, it's not clear whether there will be jfr support for the Zero variant JVM. At this point, when StartFlightRecording option is being used for a Zero JVM it asserts/crashes. It seems more appropriate to

Re: RFR: 8203410: Zero: Disable jfr feature by default

webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203410/webrev.02/ Cheers, Severin > /Erik > > > On 2018-05-18 06:57, Severin Gehwolf wrote: > > Hi, > > > > Currently the jfr (Flight Recorder) feature is being built by default > > for Zero JVMs. H

8203924: Zero: bootcycle-images build fails on x86_64

Hi, Could I please get a review of this one-liner fix for a bootcycle- images build of the Zero variant (on x86_64)? The proposed change is to use the big java settings (over small) for the jdk.compiler's annotation processing. Thoughts? diff --git a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gm

Re: 8203924: Zero: bootcycle-images build fails on x86_64

Hi Erik, On Wed, 2018-05-30 at 09:09 -0700, Erik Joelsson wrote: > Hello, > > On 2018-05-30 03:00, David Holmes wrote: > > Hi Severin, > > > > On 30/05/2018 7:15 PM, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get a revi

[Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

Forwarding to build-dev.--- Begin Message --- Just for the completeness, this is a normal openSUSE package build with --with-system-jpeg and --with-system-lcms. Maybe the LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were able to build jdk-11+18 with bundled jpeg and lcms without

[8u] RFR: 8205104: EXTRA_LDFLAGS not consistently being used

Hi, This is a JDK 8u specific problem. It's not applicable to 10/11 since the build system has changed. Make files in JDK 8 live in the hotspot tree, hence, I'm also including hotspot-dev. The issue at hand is that linker flags are not consistently passed down to individual library builds. Specifi

Re: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path

ccache > handling code in toolchain.m4 still give you the behaviour you want from > doing the backport? Thanks, Severin > Thanks > Kevin > > > > > > On 19/06/2018 07:23, Severin Gehwolf wrote: > > Hi Kevin, > > > > On Mon, 2018-06-18 at 21:

Re: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path

Hi Erik, On Tue, 2018-06-19 at 07:06 -0700, Erik Joelsson wrote: > Hello, > > On 2018-06-19 06:30, Severin Gehwolf wrote: > > Hi Kevin, > > > > Thanks for your help! Adding in build-dev for additional input. > > > > On Tue, 2018-06-19 at 13:51 +01

[8u] RFR: 8148351: Only display resolved symlink for compiler, do not change path

Hi, After discussion in [1], please review this revised JDK 8u backport of JDK-8148351. When the compiler is a symlink to ccache it'll continue to use it's work-around to keep the Oracle JDK 8 build working. If the compiler isn't a symlink it'll print this as a configure message and won't do the c

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

On Fri, 2018-06-22 at 12:53 +0200, John Paul Adrian Glaubitz wrote: > Hi Fridrich! > > On 06/21/2018 02:34 PM, Fridrich Strba wrote: > > Yes, I have tested this consolidated version and it builds just fine for me. > > I have just verified that the problem exists on Debian unstable as well when >

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

On Fri, 2018-06-22 at 13:31 +0200, John Paul Adrian Glaubitz wrote: > Hi Severin! > > On 06/22/2018 01:19 PM, Severin Gehwolf wrote: > > > Now, before I create the bug report, do you happen to know which changeset > > > introduced the regression? We usually inc

[8u] RFR: 8206425: .gnu_debuglink sections added unconditionally when no debuginfo is stripped

Hi, Please review this 8u-only change. JDK 10+ are not affected. For JDK 8 builds which don't perform any debug info stripping no .gnu_debuglink sections should get generated. The fix is to move the objcopy --add-gnu-debuglink calls into branches which actually perform some stripping: all_strip,

Re: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally when no debuginfo is stripped

Hi David, On Fri, 2018-07-06 at 11:53 +1000, David Holmes wrote: > Hi Severin, > > On 6/07/2018 2:41 AM, Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u-only change. JDK 10+ are not affected. > > > > For JDK 8 builds which do

Re: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally when no debuginfo is stripped

On Fri, 2018-07-06 at 19:41 +1000, David Holmes wrote: > > > > OK to get this pushed to JDK 8u? > > You have your code reviews. Now you need to request approval as per: > > http://openjdk.java.net/projects/jdk8u/approval-template.html Yes, thanks: http://mail.openjdk.java.net/pipermail/jdk8u-de

Re: [11] RFR (XS) 8207047: Multiple VM variants build fail

Adding build-dev as this is a build change. On Thu, 2018-07-12 at 12:12 +0300, Boris Ulasevich wrote: > Hi all, > > Please review a simple patch: > http://cr.openjdk.java.net/~bulasevich/8207047/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8207047 > > Collision happens on JFR gensrc tool

RFR: 8207057: No debug info for assembler files

Hi, Could I please get a review of this build fix? The problem is that no debug info gets ever generated for assembler files in hotspot. The proposed fix is to generated debug info via CFLAGS_DEBUG_SYMBOLS if so requested. For example --with-native-debug-info=none no debug info is generated. --wit

Re: RFR: 8207057: No debug info for assembler files

e need to introduce a separate ASFLAGS_DEBUG_SYMBOLS variable for > this to work. I'll work on that then. Thanks, Severin > /Erik > > On 2018-07-12 08:17, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review of this build fix? The problem

Re: RFR: 8207057: No debug info for assembler files

On Fri, 2018-07-13 at 09:29 +0200, Severin Gehwolf wrote: > Hi Erik, > > Thanks for the review! > > On Thu, 2018-07-12 at 09:47 -0700, Erik Joelsson wrote: > > Hello Severin, > > From looking at your jdk-submit job I can already say that it's not working > >

Re: RFR: 8207057: No debug info for assembler files

On Fri, 2018-07-13 at 10:46 +0200, Severin Gehwolf wrote: > New webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8207057/webrev.02/ > > This leaves non-GCC toolchains unchanged since I don't know the > relevant flags (if they even exist). I'd be happy to add th

Re: RFR: 8207057: No debug info for assembler files

gt; > > On 2018-07-13 01:46, Severin Gehwolf wrote: > > On Fri, 2018-07-13 at 09:29 +0200, Severin Gehwolf wrote: > > > Hi Erik, > > > > > > Thanks for the review! > > > > > > On Thu, 2018-07-12 at 09:47 -0700, Erik Joelsson wrote: >

[8u] RFR 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped]

Hi, This work started as a patch for JDK-8207234[1], but turned out to become a 8-backport of JDK-8036003[2] using the old build logic and with backwards-compatibilty. We are facing an issue where .gnu_debuglink sections get generated unconditionally on the various JDK libs (serviceability, securi

Re: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally when no debuginfo is stripped

Hi Andrew, On Sun, 2018-07-15 at 03:11 +0100, Andrew Hughes wrote: > On 6 July 2018 at 09:26, Severin Gehwolf wrote: > > Hi David, > > > > On Fri, 2018-07-06 at 11:53 +1000, David Holmes wrote: > > > Hi Severin, > > > > > > On 6/07

Re: [8u] RFR 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped]

exist. $$(eval $$(call MakeDir,$$($1_OBJECT_DIR) $$($1_OUTPUT_DIR))) $$(foreach d,$$($1_SRC), $$(if $$(wildcard $$d),,$$(error SRC specified to SetupNativeCompilation $1 contains missing directory $$d))) Thanks, Severin > On 2018-07-17 05:54, Severin Gehwolf wrote: > > Hi, > >

[8u] RFR: 8207402: Stray *.debuginfo files when not stripping debug info

Hi, Here is another little fix for JDK 8u for the no-debug-info-stripping use-case. It depends on JDK-8207234 which introduces --with-native- debug-symbols=[...] configure flag. Basically when no stripping of debuginfo should be happening no .debuginfo/.diz files should be produced at all by the b

Re: [8u] RFR 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped]

ollar on > $(STRIP_POLICY). Then it gets evaluated when the macro is called instead > of when it is defined. > > /Erik > > > On 2018-07-17 09:01, Severin Gehwolf wrote: > > Hi Erik, > > > > On Tue, 2018-07-17 at 07:24 -0700, Erik Joelsson wrote: > > > Good

Re: [8u] RFR 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped]

k8u-dev/2018-July/007670.html > /Erik > > > On 2018-07-18 06:42, Severin Gehwolf wrote: > > Hi Erik, > > > > Latest webrev with default param over changes in the jdk tree: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/webrev.02/ > > > &

Re: [8u] RFR 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped]

Hi Erik, On Wed, 2018-07-18 at 18:10 +0200, Severin Gehwolf wrote: > webrev with info line removed: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/webrev.03/ > > HG-export: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/JDK-8036003.jdk8.export.patch >

  1   2   3   4   >