Re: RFR: 8330820: Remove remnants of operator_new.cpp in build system

On Mon, 22 Apr 2024 13:11:02 GMT, Magnus Ihse Bursie wrote: > In [JDK-8282469](https://bugs.openjdk.org/browse/JDK-8282469), the file > operator_new.cpp was removed from Hotspot. Unfortunately, some ugly hacks > related to this file remained in the build system. They should be removed.

Re: CFV: New Build Group Member: Julian Waters

Vote: yes Tim On 9/20/23 03:21, Magnus Ihse Bursie wrote: nominate Julian Waters

Re: cant remove directories from my https://cr.openjdk.org/ folder

Hello, Vicente: rename myfolder .trash/myfolder as indicated at [1], I get: Couldn't rename file "/public_html/myfolder" to "/public_html/.trash/myfolder" Please try it again.  I fixed the umask on your public_html/.trash directory. Using sftp and renaming files into your .trash directory

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

On 3/29/2023 6:21 PM, Dima Kogan wrote: Package: installation-reports Severity: grave Hi. I just installed a bookworm candidate. This worked OK through partitioning and reboot, but I cannot boot into the system. This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA. I'm

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

On 3/29/2023 6:21 PM, Dima Kogan wrote: Package: installation-reports Severity: grave Hi. I just installed a bookworm candidate. This worked OK through partitioning and reboot, but I cannot boot into the system. This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA. I'm

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

On 3/29/2023 6:21 PM, Dima Kogan wrote: Package: installation-reports Severity: grave Hi. I just installed a bookworm candidate. This worked OK through partitioning and reboot, but I cannot boot into the system. This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA. I'm

Bug#1033200: apt, apt-get, aptitude and others have been failing for an extended period.

On 3/19/2023 10:19 AM, WILLIAM ORVILLE RICHMOND wrote: Err:1 http://deb.debian.org/debian bullseye/main amd64 lynx-common all 2.9.0dev.6-3~deb11u1   Connection failed [IP: 199.232.34.132 80] Err:2 http://deb.debian.org/debian bullseye/main amd64 lynx amd64 2.9.0dev.6-3~deb11u1   Connection

Re: RFR: 8301267: Update of config.guess broke build on WSL

On Fri, 27 Jan 2023 21:11:00 GMT, Erik Joelsson wrote: > After JDK-8300805, config.guess has changed output when running on WSL. This > is caused by the autoconf-config.guess now reporting it as > `x86_64-pc-linux-gnu` instead of `x86_64-unknown-linux-gnu`, and our wrapper > script is

Re: mail.openjdk.org server issues

Hello On 7/6/22 13:19, some-java-user-99206970363698485...@vodafonemail.de wrote: Hello, it appears for the past couple of days mail.openjdk.org is having server issues. In nearly all cases the server responds with an HTTP 5xx error. At the moment that seems to be "504 Gateway Time-out",

Need OpenJDK to be used on PowerPC for our products.

Forwarded Message Subject:RE: Need OpenJDK to be used on PowerPC for our products. Date: Thu, 6 Jan 2022 19:16:10 + From: Dipendu Ghosh To: mailman-owner Hi, I am an Engineer from Keysight Technologies. In Keysight, we have a few products where we use

Re: CFV: New Build Group Member: Aleksey Shipilev

Vote: yes Tim On 11/10/21 06:06, Magnus Ihse Bursie wrote: I hereby nominate Aleksey Shipilev (shade) to Membership in the Build Group.

Re: Running jdk's tests to produce coverage report

Hello Stefanos On 11/3/21 08:12, Chaliasos, Stefanos wrote: Hello, I'm trying to compute code coverage for langtools in the JDK repo on a Ubuntu 18.04 machine using JDK 18 for the compilation. I have run the following commands: ``` cd /home/user git clonehttps://github.com/openjdk/jdk.git

Re: [jdk17] RFR: 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot

On Fri, 9 Jul 2021 19:45:09 GMT, Erik Joelsson wrote: > Add missing make dependency in Main.gmk. Looks good - Marked as reviewed by tbell (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/239

Re: RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle

On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt wrote: > The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 > from early December, so does not include all the JDK 16 GA functionality. > This leads to build issues after JDK-8263621 which uses a method not included > in

Re: RFR: JDK-8259656: fixpath.sh changes broke _NT_SYMBOL_PATH in RunTests.gmk

On Mon, 8 Feb 2021 18:05:20 GMT, Erik Joelsson wrote: > Adding FIXPATH_BASE in RunTestsPrebuilt.gmk as that's needed for the FixPath > make macro to work. Looks good. - Marked as reviewed by tbell (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2460

Re: RFR: JDK-8260669: Missing quotes in fixpath.sh

On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson wrote: > The build on Windows can fail if certain directory names are present in root > directory of the workspace. In particular I've observed that the single > letter 'p' is triggering this problem. This is caused by missing quotes > around

Re: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12

On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson wrote: > To guarantee backwards compatible binaries on Macos, we use the option > -mmacosx-version-min. This is currently set to 10.9, which is a really > ancient version. I propose we bump this to 10.12, which is still a rather > conservative

Re: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12

On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson wrote: > To guarantee backwards compatible binaries on Macos, we use the option > -mmacosx-version-min. This is currently set to 10.9, which is a really > ancient version. I propose we bump this to 10.12, which is still a rather > conservative

Re: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features

On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson wrote: > This patch changes how the docs-reference make target behaves to better > support the requirements for it. This target is used to generate javadocs in > a more stable way between releases, so that they those docs are better suited > for

Re: RFR: JDK-8257789: Fix incremental build of test-image and bundles

On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson wrote: > When building the test-bundle incrementally, it always gets rebuilt. This is > caused by the prepare-test-image target in TestImage.gmk, where we create a > README file as part of a recipe for a PHONY target. This means that the > README

Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v3]

On Wed, 2 Dec 2020 18:54:17 GMT, Erik Joelsson wrote: >> After fixing JDK-8256810 and starting to look into backporting it, I >> discovered more potential failing cases. Certain versions of GCC may >> sometimes output multiple prerequisite files on the same line. I think the >> easiest way to

Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v2]

On Wed, 2 Dec 2020 21:41:26 GMT, Erik Joelsson wrote: >> test/make/TestFixDepsFile.gmk line 60: >> >>> 58: $(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected >>> 59: $(ECHO) " /foo/baz" >> $(DEPS_FILE).expected >>> 60: $(DIFF) $(DEPS_FILE).expected

Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v2]

On Wed, 2 Dec 2020 17:55:18 GMT, Erik Joelsson wrote: >> After fixing JDK-8256810 and starting to look into backporting it, I >> discovered more potential failing cases. Certain versions of GCC may >> sometimes output multiple prerequisite files on the same line. I think the >> easiest way to

Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files

On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson wrote: > After fixing JDK-8256810 and starting to look into backporting it, I > discovered more potential failing cases. Certain versions of GCC may > sometimes output multiple prerequisite files on the same line. I think the > easiest way to

New lead for the JDK 7u Project: Andrew Brygin

Infrastructure Group is sponsor of the project. As Group Leader [4], I would like to nominate Andrew Brygin [5] to be the new Project Lead. The Build Infrastructure Group is the only sponsoring group for this project. The nomination is automatically approved. Tim Bell [1] https

New lead for the JDK 7u Project: Andrew Brygin

Infrastructure Group is sponsor of the project. As Group Leader [4], I would like to nominate Andrew Brygin [5] to be the new Project Lead. The Build Infrastructure Group is the only sponsoring group for this project. The nomination is automatically approved. Tim Bell [1] https

JDK 7u Project Lead

involved in the project, the nomination is automatically approved. What remains to be done will be sending out an announcement to notify the Registrar and have it recorded. Tim Bell [1] https://mail.openjdk.java.net/pipermail/jdk7u-dev/2020-August/011040.html [2] https://mail.openjdk.java.net

JDK 7u Project Lead

involved in the project, the nomination is automatically approved. What remains to be done will be sending out an announcement to notify the Registrar and have it recorded. Tim Bell [1] https://mail.openjdk.java.net/pipermail/jdk7u-dev/2020-August/011040.html [2] https://mail.openjdk.java.net

Re: RFR: JDK-8255673: Wrong version in docs bundles

On Fri, 30 Oct 2020 17:19:56 GMT, Erik Joelsson wrote: > In JDK-8206311, when I introduced a new docs build profile, I forgot to add > the version configure arguments to it. This causes the docs bundles for > CI/promoted builds to be generated with the default adhoc version information >

Re: RFR: JDK-8255620: Build race between modulegraphs and exploded-image-optimize targets

On Thu, 29 Oct 2020 22:00:52 GMT, Erik Joelsson wrote: > When I reorganized top level docs build targets in JDK-8206311, a race was > introduced. The docs-*-modulegraph targets use the BUILD_JDK to run a build > tool. For this to work, the BUILD_JDK needs to be ready for usage. In a > normal

Re: RFR: JDK-8255620: Build race between modulegraphs and exploded-image-optimize targets

On Thu, 29 Oct 2020 22:00:52 GMT, Erik Joelsson wrote: > When I reorganized top level docs build targets in JDK-8206311, a race was > introduced. The docs-*-modulegraph targets use the BUILD_JDK to run a build > tool. For this to work, the BUILD_JDK needs to be ready for usage. In a > normal

Re: RFR: JDK-8249292: DependOnVariable macro fails on empty value

Erik: The DependOnVariable macro fails if the variable is empty. The failure is rather non intuitive as it complains that the vardeps file doesn't exist and is needed for the target. This patch make the macro treat an empty variable value just like any other value. I'm also adding test cases

Re: [15] RFR: JDK-8249255: Build fails if source code in cygwin home dir

Erik: > The fix is to make sure WORKSPACE_ROOT in basics.m4 only gets values > that have been fixed using UTIL_FIXUP_PATH. Looks good. Tim This is a fix for the problem reported by Ty in this thread: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027917.html The problem is the

Re: RFR: JDK-8244945: Mark VS2019 as supported and default

Erik: When updating the Windows toolchain at Oracle, I forgot to also mark the new toolchain VS2019 as supported in configure. This has the effect that configuring with VS2019 causes a warning to be printed. We should also make configure prefer 2019 over 2017 if both are available. Bug:

Re: RFR: JDK-8244247: Build failures after sjavac cleanup

Erik: Looks good. Tim After the sjavac cleanup in JDK-8244036 (and the subsequent fix of the javac server usage in JDK-8244210), two more build failures have been noted. The bootcycle build fails and the test-make target fails the tests of SetupJavaCompilation. The bootcycle build fails

Re: RFR: JDK-8244210: The javac server is never used

Erik: Looks good. Tim Hello, A minor mistake in JDK-8244036 is causing the javac server to never be used, which is rather severly increasing build times. Before that change, the global variable ENABLE_SJAVAC was used to determine if the server should be activated. After the change, the

Re: RFR: 8243633: Remove cups dependency when building linux at Oracle

Mikael: Looks good. Tim On 2020-04-27 12:30, Mikael Vidstedt wrote: Ah, good point/catch! I updated the title of the JBS issue. New webrev: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.01/open/webrev/ incremental:

Re: RFR: JDK-8243510: AbsPathsInImage.java fails intermittently

Erik: Bug: https://bugs.openjdk.java.net/browse/JDK-8243510 Webrev: http://cr.openjdk.java.net/~erikj/8243510/webrev.01/ Looks good. Tim

Re: RFR: 8243591: Change to GCC 9.2 for building Linux/aarch64 at Oracle

Mikael: The gcc version used to build linux/x64 at Oracle was recently bumped to 9.2.0, linux/aarch64 should follow suit: JBS: https://bugs.openjdk.java.net/browse/JDK-8243591 webrev:

Re: RFR: 8243590: Bump boot jdk to JDK 14 on aarch64 at Oracle

Mikael: The (minimum) boot JDK was recently bumped to JDK 14, and that needs to be reflected in the configuration for linux-aarch64 builds at Oracle as well: JBS: https://bugs.openjdk.java.net/browse/JDK-8243590 Webrev:

Re: RFR: JDK-8242468: VS2019 build missing vcruntime140_1.dll

Erik: Looks good. When building with VS2019, there is a new runtime library, vcruntime140_1.dll, that we need to bundle along with the others. This patch sets this up all through the build. Bug: https://bugs.openjdk.java.net/browse/JDK-8242468 Webrev:

Re: RFR: JDK-8242463: ProcessTools.createNativeTestProcessBuilder() in testlib needs jdk/bin on PATH on Windows

Erik: Looks good to me as well. Tim The test open/test/hotspot/jtreg/testlibrary_tests/process/TestNativeProcessBuilder.java fails when building the JDK with VS2019. More specifically, it fails if the JDK under test is built with a different version of VS than the boot JDK. The cause of

Re: RFR (xs): 8238515 - Backout JDK-8236092 from jdk/jdk

Jesper: Looks good to me as well. Tim On 2/4/20 6:37 PM, David Holmes wrote: Looks good and trivial. Thanks, David On 5/02/2020 12:36 pm, Jesper Wilhelmsson wrote: Hi. I need a review for this tiny change. The "ea" suffix was removed from the JDK 14 version string with JDK-8236092. Since

Re: RFR: JDK-8237914: The test-make target does not fail on test failure

Erik: When running the make tests for the build itself, RunTest.gmk currently does not attempt at parsing the results. Because of this, failures aren't detected and so the build does not fail if a test fails. This patch adds a very rudimentary parsing, defining the whole test run as 1 test

Re: RFR: JDK-8237879: make 4.3 breaks build

Hi Magnus: On 1/29/20 6:01 AM, Erik Joelsson wrote: On 2020-01-29 02:58, Magnus Ihse Bursie wrote: I got tired of the code duplication of "$(call DependOnVariableFileName, $1, $2)". Here's a new webrev with shorter lines, and hopefully better readability overall:

Re: RFR: JDK-8237879: make 4.3 breaks build

Erik: Please review this fix to make the build compatible with GNU make 4.3. See bug for details on the fix, but this change basically adds an empty rule like this for the example failure:

Re: [rdo-users] [Meeting] RDO meeting (2020-01-05) minutes

For my understanding, what’s the latest RDO release which will be supported on CentOS 7 ? Thanks Tim > On 15 Jan 2020, at 15:55, Javier Pena wrote: > > == > #rdo: RDO meeting - 2020-01-15 > == > > > Meeting started by jpena at

Re: [rdo-dev] [rdo-users] [Meeting] RDO meeting (2020-01-05) minutes

For my understanding, what’s the latest RDO release which will be supported on CentOS 7 ? Thanks Tim > On 15 Jan 2020, at 15:55, Javier Pena wrote: > > == > #rdo: RDO meeting - 2020-01-15 > == > > > Meeting started by jpena at

Re: RFR: JDK-8235687: Contents/MacOS/libjli.dylib cannot be a symlink

Erik: Looks good. Tim To be able to fully sign and notarize a jdk-bundle on MacOS, the file Contents/MacOS/libjli.dylib cannot be a symlink. The easy fix is to simply make it a normal file. Longer term we will evaluate what this file is actually needed for, but for now, we just need to make

Re: RFR: JDK-8235686: Add more custom hooks in Bundles.gmk

Erik: We need to customize the image dirs in order to support the new Macos signing requirements at Oracle. To support this, we need Bundles.gmk to accept more variable overrides for where the various images are located. Bug: https://bugs.openjdk.java.net/browse/JDK-8235686 Webrev:

Re: RFR: JDK-8233112: Exclude SVG files from build comparison

Erik: This patch fixes the COMPARE_BUILD baseline. The SVG files generated by GraphViz are non-deterministic, so adding a sed filter to compensate. There is also an issue since jpackage was added, where we now have executables as resources in lib/modules. Those need to be compared as

Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports

Mikael: Looks good to me as well. Tim On 2019-11-22 06:10, Erik Joelsson wrote: Looks good. /Erik On 2019-11-20 12:03, Mikael Vidstedt wrote: I noticed that most of the configure options include the default value in the help string (in brackets), so here’s an updated webrev which does

Re: RFR 8233880: Support compilers with multi-digit major version numbers

Florian: The current regular expression only matches one digit before the first dot. Bug: Webrev: Tested against GCC 10.0.0. configure no longer prints a C/C++ version mismatch

Re: RFR: JDK-8232569: Use test image from different jib profile for testing

Erik: Building and publishing a test image for every Jib build profile is a waste of resources. We need to be able to specify a test image from a different profile at test time when running "run-test-prebuilt". This patch takes the concept used for the -jcov profiles and makes it more

Re: RFR: JDK-8232572: Add hooks for custom output dir in Bundles.gmk

Erik: Our custom distribution packaging logic needs to be able to override the output directory of bundles. This patch adds an OUTPUT_DIR parameter to the SetupBundles macro. It also adds logging of the bundles being created. The added % in the filter makes it possible to extend specific

Re: RFR: JDK-8223998 Missing MakeDir in ExecuteWithLog

Magnus: Bug: https://bugs.openjdk.java.net/browse/JDK-8223998 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8223998-missing-makedir-in-executewithlog/webrev.01 Looks good. Tim

Re: RFR: JDK-8231594: Configure fails on some Linux systems

Erik: In my recent change JDK-8206125, I introduced a bash conditional that checks if a string starts with ~. That check seems to fail on some Linux systems unless the ~ is quoted. That's a very dark corner for the shell to be in... Bug: https://bugs.openjdk.java.net/browse/JDK-8231594

Re: RFR: JDK-8231467: Missing make prerequisite declaration corrupts make dependency files on Windows

Erik: Looks good to me as well. Tim On 2019-09-25 11:59, Magnus Ihse Bursie wrote: Looks good to me. /Magnus 25 sep. 2019 kl. 19:59 skrev Erik Joelsson : In JDK-8217728 I introduced a new rule in SetupNativeCompilation which combines all the generated *.d dependency files into one for

Re: RFR: JDK-8210794: Incorrect escaping of $ORIGIN in native test libraries

Erik: This patch fixes an escaping issue that causes a broken runpath to be set in test libraries. Bug: https://bugs.openjdk.java.net/browse/JDK-8210794 Webrev: http://cr.openjdk.java.net/~erikj/8210794/webrev.01/index.html Looks good. Tim

Re: RFR: JDK-8206125: [windows] cannot pass relative path to --with-boot-jdk

Erik: On Windows, the BASIC_FIXUP_PATH macro in configure does not actually convert relative paths to absolute like the description claims. This patch takes the implementation already present for Unix and applies it to all the different Windows environment specific implementations. I have

[issue30701] Exception parsing certain invalid email address headers

Tim Bell added the comment: This appears to be the same issue as subsequently reported in #34155. -- ___ Python tracker <https://bugs.python.org/issue30

Re: Mac OS (Mojave / Xcode 10.3) build issue..

Sundar: I filed: JDK-8228619 "[macos 10.14.x] (Mojave) build issue: /usr/local/bin/nm reports no symbols" https://bugs.openjdk.java.net/browse/JDK-8228619 At Oracle, JDK 14 is built on macOS 10.13 (High Sierra). This will need investigation in the future, when the build platform moves to

Re: RFR [XS] 8227834: build.log output from failing commands : include the hs_error file path in case of crashes in build - was :RE: build.log: Output from failing command(s) repeated here - do not m

Hello Matthias: Hello I prepared a small change to address the mentioned issue . Please review ! Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227834 http://cr.openjdk.java.net/~mbaesken/webrevs/8227834.0/ Looks good. Tim

Re: RFR(XS): 8227636: Fix output dir for jlink_jre target in Images.gmk

Hello, Christoph: with today’s push for „8227578: Wrong JRE targets in Images.gmk after JDK-8219971” I didn’t catch all issues with the JRE target and especially not the one that’s causing our build errors. But now I’ve got it  Please review this one line fix. Bug:

Re: Fwd: Problem with build

Hello On 07/12/19 02:52, laila fal wrote: Hello, I downloaded a project from https://github.com/openjdk-mirror/jdk7u-hotspot/tree/master/src/share/vm/gc_implementation/g1 jdk7u-hotspot/src/share/vm/gc_implementation/g1/ and also from

Re: How to troubleshoot build failure on windows cygwin

Looks like you are using a newer Visual Studio toolchain: 'C:\PROGRA~2\MICROS~1\2017\PROFES~1\VC\Tools\MSVC\14.16.27023\ See below: On 07/11/19 12:35, Moshe Zuisman wrote: now I pulled last source (used get_ssource.sh) and - same result: [...snip...] *Generating Code...sh

Re: RFR(S): 8227578: Wrong JRE targets in Images.gmk after JDK-8219971

Hi, Christoph: please review this little bugfix in Images.gmk. Bug: https://bugs.openjdk.java.net/browse/JDK-8227578 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227578.0/ I guess it's only relevant when building "legacy-bundles" or something that builds jre-images. However in that

Re: CFV: New Build Group Member: Matthias Baesken

Vote: yes Tim On 06/26/19 01:29, Volker Simonis wrote: I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build Group.

Re: OpenJDK 11u backport of JDK-8148188: Enhance the security libraries to record events of interest

On 06/22/19 15:18, Langer, Christoph wrote: Thanks, David. Then I probably did the right thing by manually creating the backport bug. You did the right thing. cc-ing ops@o.j.n: Maybe you want to have a look why hgupdater failed in this case? hgupdater found a confidential backport record

Re: RFR: JDK-8226538: find-files.gmk gets corrupted if tab completion is used before running make first

Erik: I'm changing TestMake.gmk to accept an input parameter for a target file to which the list of targets is printed to instead of stdout. This solves the fundamental design problem. Sounds good. Bug: https://bugs.openjdk.java.net/browse/JDK-8226538 Webrev:

Re: RFR: JDK-8226269: Race in SetupProcessMarkdown

Erik: This patch adds parentheses around the affect command. I have verified that the exploded image no longer gets any empty man pages. This fix is intended for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8226269 Webrev: http://cr.openjdk.java.net/~erikj/8226269/webrev.01/ Looks

Re: RFR: JDK-8209381: Default CDS classlist generation should run with an explicit locale setting

Erik: Looks good to me as well. Tim On 06/04/19 16:59, Ioi Lam wrote: Looks good! Thanks for the patch. Ioi On Jun 4, 2019, at 2:53 PM, Erik Joelsson wrote: Hello, Please review this fix for the default CDS classlist generation. This patch adds an explicit English locale to the

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

in buildjdk-spec.gmk.in. New webrev, only changed in buildjdk-spec.gmk.in: http://cr.openjdk.java.net/~erikj/8217739/webrev.02/ /Erik On 2019-06-04 07:53, Tim Bell wrote: Erik: Looks good. Tim This is a fix for a problem brought up on this list [1]. The main issue is that when cross compiling

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

Erik: Looks good. Tim This is a fix for a problem brought up on this list [1]. The main issue is that when cross compiling, and creating a buildjdk during the build, the UnixConstants.java cannot necessarily be reused between the target JDK and the buildjdk. While investigating this, I came

Re: RFR: JDK-8225140: Build fails if directory contains 'unix'

Erik: This patch changes the filter mechanics to only apply to the path relative to the workspace root. I also changed the filter token from "unix" to "/unix/" to avoid the risk of matching substrings in directories in the future. Bug: https://bugs.openjdk.java.net/browse/JDK-8225140 Webrev:

Re: RFR: JDK-8219788: Configure recommends JDK 8

Erik: This patch changes the help text printed when the bootjdk is missing to "OpenJDK distributions are available at http://jdk.java.net/.; and removes all the OS specific help texts for that particular dependency. Bug: https://bugs.openjdk.java.net/browse/JDK-8219788

Re: RFR: JDK-8224257 : fix issues in files generated by pandoc

Jon: Looks good to me as well. Tim On 05/30/19 06:27, Erik Joelsson wrote: Looks good to me, but I also contributed the build changes. /Erik On 2019-05-29 15:44, Jonathan Gibbons wrote: Please review a fix to provide a new build-time tool to fix up the output generated by the "pandoc"

Re: RFR: JDK-8224011: Failure handling in ExecuteWithLog fails in run-test-prebuilt

Erik: When running tests using "make run-test-prebuilt", we bypass a lot of Init.gmk. One of the things we skip is initialization of the make-support/failure-logs dir. This causes make to print errors about failing to copy files into that directory if for example the AOT compilation fails,

Re: RFR: JDK-8224145: Build compare script fails intermittently on test image native libraries

Erik: Since I added comparing of the test image, we have seen some intermittent compare failures in the baseline compare builds we run. The root cause of these failures are that the native libraries in the test image are not stripped of debug information, like the product native libraries are.

Re: RFR: JDK-8224677: Dtrace .d files clash with make dependency .d files

Erik: Since JDK-8217728, where I introduced some optimizations for handling of the generated make dependency files for native compilation, building hotspot incrementally on Solaris has been broken. The reason for the breakage is that there is a clash between the *.d (header) files created by

Re: RFR: JDK-8223627: jdk-13+20 bundle name contains null instead of ea

Erik: Looks good to me as well. Tim On 05/09/19 07:02, David Holmes wrote: Looks good. David - On 9/05/2019 11:44 pm, Erik Joelsson wrote: In JDK-8223464 I managed to introduce a bug. The reference to the new property for the PRE string is misspelled in one location. Bug:

Unit conversions between model field value and form field value

Hi, I have a model with an integer field storing a duration in hours, while I want to present that to users in a form in days. (The choice of these different units is imposed by other factors not under my control.) So, when saving a form, I need to convert a value in days to hours by

Re: RFR: JDK-8223464: Improve version string for Oracle CI builds

Erik: Looks good. Thanks for doing this. Tim On 05/07/19 07:21, Erik Joelsson wrote: This change changes how the version string will look in Oracle CI builds. A string that current looks like this: 13-internal+0-jdk13-jdk.844 Will instead look like this: 13-ea+0-844 For projects, the

Re: RFR: JDK-8223309: test failing due to self-assign-overloaded

Erik: Looks good. Tim I agreed to sponsor this off list. While doing a sanity build locally with the compiler we use at Oracle (Xcode 10.1), I discovered that clang does not let us use unknown warnings like we do with GCC: error: unknown warning option '-Wno-self-assign-overloaded'; did you

Re: RFR: JDK-8222913: Add Jib support for VERSION_EXTRA*

Erik - Looks good to me as well. Tim On 04/24/19 16:27, Mikael Vidstedt wrote: Wow, so proactive of you. Ship it! Cheers, Mikael On Apr 24, 2019, at 4:00 PM, Erik Joelsson wrote: JDK-8207849 added support for extra version numbers in the java version string. Now we need to use at least

Re: RFR: JDK-8222735: Update doc/building.md with current Oracle build platforms and compilers

Erik: When updating the compilers used at Oracle earlier this year, I forgot to keep building.md up to date. This needs to be fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8222735 Webrev: http://cr.openjdk.java.net/~erikj/8222735/webrev.01/ Looks good. Tim

Re: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC

On 04/08/19 07:28, Erik Joelsson wrote: > I'm now looking for another Hotspot reviewer. > > http://cr.openjdk.java.net/~erikj/8221851/webrev.04/ I'm not a Hotspot Reviewer, however the build changes look good FWIW. Tim Hello, On 2019-04-05 15:46, Kim Barrett wrote: On Apr 5, 2019, at 11:09

Re: RFR: JDK-8221996: Bootcycle build broken

Erik: Looks good. Tim On 04/04/19 12:56, Erik Joelsson wrote: I found the issue. It was broken before too, but the old piping construct just ignored the error (but it was still printed). Fixed by making sure the bootcycle-build directory exists before calling the bootcycle build. Bug:

Re: RFR: JDK-8217728: Speed up incremental rerun of "make hotspot"

also been renamed. Webrev: http://cr.openjdk.java.net/~erikj/8217728/webrev.02/ /Erik On 2019-04-02 14:26, Tim Bell wrote: Erik: This patch improves general incremental build performance of native binaries, which in particular improves performance for rebuilding hotspot. Specifically

Re: RFR: JDK-8221764: Reduce make Init.gmk logging overhead

Erik: The Init.gmk and InitSupport.gmk makefiles provide the foundational framework for bootstrapping the build. That bootstrap process has grown over time and is starting to take significant time to execute on Windows. One reason for this is that every extra command executed at this level gets

Re: RFR: JDK-8217728: Speed up incremental rerun of "make hotspot"

Erik: This patch improves general incremental build performance of native binaries, which in particular improves performance for rebuilding hotspot. Specifically it removes overhead in the make file processing. Two major issues are addressed: 1. Long ago, I had managed to introduce an O(n^2)

Re: RFR: JDK-8221762: Improve Main.gmk/FindTests.gmk bootstrap time

Erik: With the new run-test test running framework, we introduced FindTests.gmk, which among other things, parses all the jtreg TEST.groups files to generate make targets for each group. While this is very nice, the current implementation in FindTests.gmk adds significant time to a simple "do

Re: RFR: JDK-8189861: Refactor CacheFind

Erik: The macro CacheFind is a bit awkward to use with FillCacheFind. The naming is also not that great. This patch tries to improve this situation. The main difference is naming of the macros. Now the main entry point is "FindFiles". There are a couple of others as well, see MakeBase.gmk for

Re: RFR: Rmic build for java.management.api has bad incremental behavior

Erik: In Rmic-java.management.api.gmk, there is a special extra rule defined to move the generated class and java files into different directories. This construct doesn't really work well in make and on incremental builds, one of the recipes is always executed. I'm rewriting this by

Re: RFR: JDK-8220530: Build compare script does not compare the contents of the test image

Erik: This patch adds comparison of the test image, if present in both build output directories. I also cleaned away comparing of some old Oracle closed images that no longer exist. Bug: https://bugs.openjdk.java.net/browse/JDK-8220530

Re: RFR: JDK-8205934: Define jdk -source/-target version in version-numbers file

Erik: To make it easier to update the major version in the future, we should define a make variable for the -source/-target version number used when compiling jdk classes and have it be initiated through make/common/version-numbers, like all other version numbers. This patch does just that.

Re: RFR: JDK-8221414: Bump required boot jdk version to 12

Erik: Looks good to me as well. Tim On 03/25/19 13:03, Mikael Vidstedt wrote: Looks good. Cheers, Mikael On Mar 25, 2019, at 3:44 PM, Erik Joelsson wrote: With the release of JDK 12 it is now time to update the required boot jdk version for JDK 13 (to 12). This patch changes the

Re: RFC: Update test documentation by deleting "cd test && make"

David, JingTian, Leslie Zhai: On 25/03/2019 4:23 pm, Jing Tian wrote: Hi David, Thanks for your review. Could you please sponsor it for me? Sure - once someone from the build team also gives the okay. Looks good to me. Tim David Thanks a lot. Cheers, JingTian 在 2019/3/25 11:59,

Re: RFR: JDK-8220445: Support for side by side MSVC Toolset versions

Erik: Sorry, forgot about this. Since I modified that patch, I need another reviewer before I can push it. So, anyone interested in reviewing this? Webrev: http://cr.openjdk.java.net/~erikj/8220445/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8220445 Looks good. Tim /Erik

Re: RFR: JDK-8220445: Support for side by side MSVC Toolset versions

Erik: Sorry, forgot about this. Since I modified that patch, I need another reviewer before I can push it. So, anyone interested in reviewing this? Webrev: http://cr.openjdk.java.net/~erikj/8220445/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8220445 /Erik On 2019-03-19

  1   2   3   4   5   6   7   8   9   10   >