Re: RFR: JDK-8252145: Unify Info.plist files with correct version strings
+1 On 26.08.2020 08:01, Erik Joelsson wrote: I realized that for LTS releases, the logic adding a numeric only $OPT string will bail out as we (Oracle) are then adding LTS to the $OPT string. To fix this, I've added an explicit setting of the new configure parameter --with-macosx-bundle-build-version from the jib configuration for CI builds. New webrev, only difference is in jib-profiles.js. http://cr.openjdk.java.net/~erikj/8252145/webrev.02/ /Erik On 2020-08-25 16:35, Sergey Bylokhov wrote: Looks fine. On 25.08.2020 07:27, Erik Joelsson wrote: On 2020-08-24 19:18, Sergey Bylokhov wrote: Hi, Erik. I would like to highlight one thing affected by this fix. The text in the default about dialog in the Swing application will be changed. For my local build: - Current text: "Java Version 1.0 (16)" - After the fix: "Java Version 16 (0)" I am not sure why the build version and as a result the CFBundleVersion is zero? The CFBundleVersion is supposed to have a version number representing the build number. In a developer build, the "VERSION_BUILD" variable is default 0. In a promoted build, that number is set to the promoted build number. In Oracle promoted builds, we will also have a CI build number, so if this change was in effect, the latest JDK 16 promoted build would have 12.477 in CFBundleVersion. /Erik On 24.08.2020 08:19, Erik Joelsson wrote: When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. 1. All Info.plist files and templates are moved to the same location in the source tree. 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 /Erik -- Best regards, Sergey.
Re: RFR: JDK-8252145: Unify Info.plist files with correct version strings
I realized that for LTS releases, the logic adding a numeric only $OPT string will bail out as we (Oracle) are then adding LTS to the $OPT string. To fix this, I've added an explicit setting of the new configure parameter --with-macosx-bundle-build-version from the jib configuration for CI builds. New webrev, only difference is in jib-profiles.js. http://cr.openjdk.java.net/~erikj/8252145/webrev.02/ /Erik On 2020-08-25 16:35, Sergey Bylokhov wrote: Looks fine. On 25.08.2020 07:27, Erik Joelsson wrote: On 2020-08-24 19:18, Sergey Bylokhov wrote: Hi, Erik. I would like to highlight one thing affected by this fix. The text in the default about dialog in the Swing application will be changed. For my local build: - Current text: "Java Version 1.0 (16)" - After the fix: "Java Version 16 (0)" I am not sure why the build version and as a result the CFBundleVersion is zero? The CFBundleVersion is supposed to have a version number representing the build number. In a developer build, the "VERSION_BUILD" variable is default 0. In a promoted build, that number is set to the promoted build number. In Oracle promoted builds, we will also have a CI build number, so if this change was in effect, the latest JDK 16 promoted build would have 12.477 in CFBundleVersion. /Erik On 24.08.2020 08:19, Erik Joelsson wrote: When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. 1. All Info.plist files and templates are moved to the same location in the source tree. 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 /Erik
Re: JDK14 cross-compile to arm64 fails to locate c++ header new
I'm not familiar with this tool for creating sysroot, but perhaps you need to add the libstdc++ dev package to get access to C++ headers? /Erik On 2020-08-25 19:46, Choe, Jiwon wrote: Hi Adrian, Thanks for the quick reply. Yes, I do have build-essential installed on the host system. I have cross-compiled jdk14 from a 32-bit x86 system to target aarch32-linux-gnueabihf before, with the same version gcc and g++. Could this still be the issue though? Thanks again, Jiwon On Tue, Aug 25, 2020 at 4:27 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: Hi Jiwon! On 8/25/20 10:06 PM, Choe, Jiwon wrote: === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: In file included from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: fatal error: new: No such file or directory #include Do you have "build-essential" installed on the host system, assuming it's Debian-based? Tools summary: * Boot JDK: openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing) (at /usr/lib/jvm/jdk-13.0.2) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc) * C++ Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++) That version of GCC looks a bit old. I'm not sure whether it's recent enough for OpenJDK 14. FWIW, I'm using a different approach for cross-building OpenJDK which works particularly easy on Debian and Ubuntu due to Multi-Arch support which allows co-installing library packages for different architectures on one system. I have documented it here: https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [ping] [11u] RFR 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC
Thank you for the quick review, Severin. -- Christoph On 2020-08-26 12:10, Severin Gehwolf wrote: On Wed, 2020-08-26 at 11:29 +0200, Christoph Göttschkes wrote: Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/ This looks fine to me. Thanks, Severin
Re: [ping] [11u] RFR 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC
On Wed, 2020-08-26 at 11:29 +0200, Christoph Göttschkes wrote: > > Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/ This looks fine to me. Thanks, Severin
[ping] [11u] RFR 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC
Hi, the webrev below still applies cleanly to jdk11u-dev. Could someone please review this downport? Thanks, Christoph On 2020-07-20 15:48, Christoph Göttschkes wrote: Hi, please review this downport of JDK-8234535 to jdk11u-dev. The changeset does not apply cleanly because of unrelated differences in the flags-cflags.m4 file surrounding the patch. Manually applying the patch was trivial. Bug: https://bugs.openjdk.java.net/browse/JDK-8234535 Commit: https://hg.openjdk.java.net/jdk/jdk/rev/eef0bf57357c Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/ Thanks, Christoph
