Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
openjdk on macOS 11.0 - Homebrew build logs
Homebrew build logs for openjdk on macOS 11.0
Build date: 2020-07-07 12:28:36
HOMEBREW_VERSION: 2.4.3-99-g9cce4c5
ORIGIN: https://github.com/Homebrew/brew
HEAD: 9cce4c5be3a740dfa6b3d14fc14eadec29b1657c
Last commit: 15 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: dd432d5adb947f753a1327acb53c4f586da20758
Core tap last commit: 11 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DEVELOPER: set
HOMEBREW_EDITOR: /usr/bin/vim
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_NO_AUTO_UPDATE: set
HOMEBREW_SKIP_OR_LATER_BOTTLES: set
CPU: octa-core 64-bit dunno
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
Clang: 12.0 build 1200
Git: 2.27.0 => /usr/local/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.0-arm64
CLT: N/A
Xcode: 12.0 => /Applications/Xcode-beta.app/Contents/Developer
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: You have uncommitted modifications to Homebrew/homebrew-core.
If this is a surprise to you, then you should stash these modifications.
Stashing returns Homebrew to a pristine state but can be undone
should you later need to do so for some reason.
cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core && git stash && git clean -d -f
Uncommitted files:
M Formula/gcc.rb
M Formula/openjdk.rb
Warning: Homebrew's sbin was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting the PATH for example like so:
echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.zshrc
2020-07-07 12:07:46 +0200
./configure
--build=aarch64-apple-darwin20
--without-version-pre
--without-version-opt
--with-version-build=14.0.1
--with-toolchain-path=/usr/bin
--with-extra-ldflags=-headerpad_max_install_names
--with-boot-jdk=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/boot-jdk/Contents/Home
--with-boot-jdk-jvmargs=-Duser.home=/var/brew/Library/Caches/Homebrew/java_cache
--with-debug-level=release
--with-native-debug-symbols=none
--enable-dtrace=auto
--with-jvm-variants=server
Runnable configure script is not present
Generating runnable configure script at /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/.configure-support/generated-configure.sh
Using autoconf at /usr/local/opt/autoconf/bin/autoconf [autoconf (GNU Autoconf) 2.69]
Warning: You are using legacy autoconf cross-compilation flags.
It is recommended that you use --openjdk-target instead.
configure: Configuration created at Tue Jul 7 12:07:49 CEST 2020.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /usr/bin/gunzip
checking for pigz... no
checking for gzip... /usr/bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for gmkdir... no
checking for mkdir... /bin/mkdir
checking for mktemp... /usr/bin/mktemp
checking for mv... /bin/mv
checking for nawk... no
checking for gawk... no
checking for awk... /usr/bin/awk
checking for printf... /usr/bin/printf
checking for greadlink... no
checking for readlink... /usr/bin/readlink
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /usr/bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /usr/bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for a sed that does not truncate output... /usr/local/Homebrew/Library/Homebrew/shims/mac/super/sed
checking for cygpath... no
checking for wslpath... no
checking for df... /bin/df
checking for cpio... /usr/bin/cpio
checking for nice... /usr/bin/nice
checking for lsb_release... no
checking for cmd.exe... no
checking for /mnt/c/Windows/System32/cmd.exe... no
checking build system type... aarch64-apple-darwin20
checking host system type... aarch64-apple-darwin20
checking target system type... aarch64-apple-darwin20
checking openjdk-build os-cpu... macosx-aarch64
checking openjdk-target os-cpu... macosx-aarch64
checking compilation type... native
checking for top-level directory... /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga
checking if custom source is suppressed (openjdk-only)... no
checking which debug level to use... release
checking which variants of the JVM to build... server
checking if absolute paths should be allowed in the build output... no, release build
checking for xcodebuild... /usr/bin/xcodebuild
checking for sdk name...
checking for sysroot... /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk
checking for toolchain path... /usr/bin
checking for extra path...
checking where to store configuration... in default location
checking what configuration name to use... macosx-aarch64-server-release
checking for zypper... no
checking for apt-get... no
checking for yum... no
checking for brew... no
checking for port... no
checking for pkgutil... pkgutil
checking for pandoc... no
checking for gmake... /usr/local/Homebrew/Library/Homebrew/shims/mac/super/gmake
configure: Testing potential make at /usr/local/Homebrew/Library/Homebrew/shims/mac/super/gmake, found using gmake in PATH
configure: Using GNU make at /usr/local/Homebrew/Library/Homebrew/shims/mac/super/gmake (version: GNU Make 3.81)
checking if make --output-sync is supported... no
checking if find supports -delete... yes
checking what type of tar was found... bsd
checking that grep (/usr/bin/grep) -Fx handles empty lines in the pattern list correctly... yes
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for ldd... no
checking for greadelf... no
checking for readelf... no
checking for dot... no
checking for hg... no
checking for git... /usr/local/Homebrew/Library/Homebrew/shims/mac/super/git
checking for stat... /usr/bin/stat
checking for time... /usr/bin/time
checking for flock... no
checking for dtrace... /usr/sbin/dtrace
checking for gpatch... no
checking for patch... /usr/bin/patch
checking for dsymutil... /usr/bin/dsymutil
checking for mig... /usr/local/Homebrew/Library/Homebrew/shims/mac/super/mig
checking for xattr... /usr/bin/xattr
checking for codesign... /usr/bin/codesign
checking if codesign certificate is present... no
checking for SetFile... /usr/bin/SetFile
checking for ulimit... /usr/bin/ulimit
checking bash version... 3.2.57
checking if bash supports pipefail... yes
checking if bash supports errexit (-e)... yes
checking for pkg-config... /usr/local/Homebrew/Library/Homebrew/shims/mac/super/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for default LOG value...
checking headless only... no
checking for graphviz dot... no, cannot generate full docs
checking for pandoc... no, cannot generate full docs
checking full docs... no, missing dependencies
checking for cacerts file... default
checking for jni library path... default
checking if packaged modules are kept... yes (default)
configure: WARNING: Value for VERSION_BUILD has been sanitized from '14.0.1' to '14'
checking for version string... 14.0.1+14
configure: Found potential Boot JDK using configure arguments
checking for Boot JDK... /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/boot-jdk/Contents/Home
checking Boot JDK version... 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)
checking for java in Boot JDK... ok
checking for javac in Boot JDK... ok
checking for javadoc in Boot JDK... ok
checking for jar in Boot JDK... ok
checking for jarsigner in Boot JDK... ok
checking if Boot JDK is 32 or 64 bits... 64
checking for local Boot JDK Class Data Sharing (CDS)... yes, created
checking for Build JDK... yes, will use output dir
configure: Xcode major version: 12
configure: Using default toolchain clang (clang/LLVM)
configure: Will use user supplied compiler CC=clang
checking for clang... /usr/bin/clang
checking resolved symbolic links for CC... no symlink
configure: Using clang C compiler version 12.0.0 [Apple clang version 12.0.0 (clang-1200.0.22.19) Target: arm64-apple-darwin20.0.0 Thread model: posix InstalledDir: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin]
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/clang accepts -g... yes
checking for /usr/bin/clang option to accept ISO C89... none needed
configure: Will use user supplied compiler CXX=clang++
checking for clang++... /usr/bin/clang++
checking resolved symbolic links for CXX... no symlink
configure: Using clang C++ compiler version 12.0.0 [Apple clang version 12.0.0 (clang-1200.0.22.19) Target: arm64-apple-darwin20.0.0 Thread model: posix InstalledDir: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin]
checking whether we are using the GNU C++ compiler... yes
checking whether /usr/bin/clang++ accepts -g... yes
checking how to run the C preprocessor... /usr/bin/clang -E
checking how to run the C++ preprocessor... /usr/bin/clang++ -E
checking for ld... ld
configure: Rewriting LD_JAOTC to "/usr/bin/ld"
configure: Using clang linker version 607.2 [@(#)PROGRAM:ld PROJECT:ld64-607.2]
checking for ar... ar
configure: Rewriting AR to "/usr/bin/ar"
checking for lipo... /usr/bin/lipo
checking for otool... /usr/bin/otool
checking for install_name_tool... /usr/bin/install_name_tool
checking for strip... strip
configure: Rewriting STRIP to "/usr/bin/strip"
checking for nm... nm
configure: Rewriting NM to "/usr/bin/nm"
checking for gobjdump... no
checking for objdump... objdump
configure: Rewriting OBJDUMP to "/usr/bin/objdump"
checking for c++filt... c++filt
configure: Rewriting CXXFILT to "/usr/bin/c++filt"
checking for jtreg... no
checking for jtreg test harness... no, not found
checking for jmh (Java Microbenchmark Harness)... no, disabled
checking for jib... no
checking if CC supports "-m64"... yes
checking if CXX supports "-m64"... yes
checking if both CC and CXX support "-m64"... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking size of int *... 8
checking for target address size... 64 bits
checking whether byte ordering is bigendian... no
checking if native warnings are errors... true (default)
checking for library containing clock_gettime... none required
checking if CC supports "-fmacro-prefix-map=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/="... yes
checking if CXX supports "-fmacro-prefix-map=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/="... yes
checking if both CC and CXX support "-fmacro-prefix-map=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/="... yes
checking if CC supports "-ffp-contract=off"... yes
checking if CXX supports "-ffp-contract=off"... yes
checking if both CC and CXX support "-ffp-contract=off"... yes
checking if BUILD_CC supports "-fmacro-prefix-map=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/="... yes
checking if BUILD_CXX supports "-fmacro-prefix-map=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/="... yes
checking if both BUILD_CC and BUILD_CXX support "-fmacro-prefix-map=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/="... yes
checking if BUILD_CC supports "-ffp-contract=off"... yes
checking if BUILD_CXX supports "-ffp-contract=off"... yes
checking if both BUILD_CC and BUILD_CXX support "-ffp-contract=off"... yes
checking what type of native debug symbols to use... none
checking for dtrace tool... /usr/sbin/dtrace
checking sys/sdt.h usability... yes
checking sys/sdt.h presence... yes
checking for sys/sdt.h... yes
checking if dtrace should be built... yes, dependencies present
checking if Hotspot gtest unit tests should be built... yes
checking cups/cups.h usability... yes
checking cups/cups.h presence... yes
checking for cups/cups.h... yes
checking cups/ppd.h usability... yes
checking cups/ppd.h presence... yes
checking for cups/ppd.h... yes
Using freetype: bundled
checking for which libjpeg to use... bundled
checking for which giflib to use... bundled
checking for PNG... no
checking for which libpng to use... bundled
checking for compress in -lz... yes
checking for which zlib to use... system
checking for system zlib functionality... ok
checking for which lcms to use... bundled
checking for cos in -lm... yes
checking for dlopen in -ldl... yes
checking if shenandoah can be built... yes
checking if zgc can be built... no, platform not supported
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
checking if cds should be enabled... yes
checking if elliptic curve crypto implementation is present... yes
checking if jtreg failure handler should be built... no, missing jtreg
checking if the CDS classlist generation should be enabled... yes
checking if any translations should be excluded... no
checking if static man pages should be copied... yes
checking if a default CDS archive should be generated... yes
checking for number of cores... 8
checking for memory size... 16384 MB
checking for appropriate number of jobs to run in parallel... 8
checking flags for boot jdk java command ... -Duser.language=en -Duser.country=US -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces -XX:SharedArchiveFile=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/configure-support/classes.jsa -Xshare:auto -Duser.home=/var/brew/Library/Caches/Homebrew/java_cache
checking flags for boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536
checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536
checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1
checking whether to use sjavac... no
checking whether to use javac server... yes
checking If precompiled header is enabled... yes
checking is ccache enabled... no
checking if build directory is on local disk... yes
checking JVM features for JVM variant 'server'... "aot cds compiler1 compiler2 dtrace epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs"
configure: creating /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/configure-support/config.status
config.status: creating /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/spec.gmk
config.status: creating /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/bootcycle-spec.gmk
config.status: creating /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/buildjdk-spec.gmk
config.status: creating /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/compare.sh
config.status: creating /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/Makefile
====================================================
A new configuration has been successfully created in
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release
using configure arguments '--build=aarch64-apple-darwin20 --without-version-pre --without-version-opt --with-version-build=14.0.1 --with-toolchain-path=/usr/bin --with-extra-ldflags=-headerpad_max_install_names --with-boot-jdk=/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/boot-jdk/Contents/Home --with-boot-jdk-jvmargs=-Duser.home=/var/brew/Library/Caches/Homebrew/java_cache --with-debug-level=release --with-native-debug-symbols=none --enable-dtrace=auto --with-jvm-variants=server'.
Configuration summary:
* Debug level: release
* HS debug level: product
* JVM variants: server
* JVM features: server: 'aot cds compiler1 compiler2 dtrace epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs'
* OpenJDK target: OS: macosx, CPU architecture: aarch64, address length: 64
* Version string: 14.0.1+14 (14.0.1)
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) (at /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/boot-jdk/Contents/Home)
* Toolchain: clang (clang/LLVM from Xcode 12.0)
* C Compiler: Version 12.0.0 (at /usr/bin/clang)
* C++ Compiler: Version 12.0.0 (at /usr/bin/clang++)
Build performance summary:
* Cores to use: 8
* Memory limit: 16384 MB
The following warnings were produced. Repeated here for convenience:
WARNING: Value for VERSION_BUILD has been sanitized from '14.0.1' to '14'
2020-07-07 12:08:03 +0200
make
images
Building target 'images' in configuration 'macosx-aarch64-server-release'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Warning: No SCM configuration present and no .src-rev
Compiling 1 files for BUILD_JFR_TOOLS
Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
Compiling 2 files for BUILD_JVMTI_TOOLS
Parsing 2 properties into enum-like class for jdk.compiler
Compiling 7 properties into resource bundles for jdk.jshell
Compiling 10 properties into resource bundles for jdk.javadoc
Compiling 19 properties into resource bundles for jdk.compiler
Compiling 12 properties into resource bundles for jdk.jdeps
ld: warning: directory not found for option '-F/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/JavaVM.framework/Frameworks'
Compiling 127 files for BUILD_java.compiler.interim
Creating support/modules_libs/java.base/server/libjvm.dylib from 921 file(s)
Creating hotspot/variant-server/libjvm/gtest/libjvm.dylib from 118 file(s)
Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s)
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/precompiled/precompiled.hpp:34:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/classfile/classLoaderData.hpp:30:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/memory/metaspace.hpp:32:
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/runtime/globals.hpp:36:10: fatal error: In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/precompiled/precompiled.hpp:34:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/classfile/classLoaderData.hpp:30:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/memory/metaspace.hpp:32:
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/runtime/globals.hpp:36:10: fatal error: 'globals_bsd_aarch64.hpp' file not found
#include OS_CPU_HEADER(globals)
^~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:607:40: note: expanded from macro 'OS_CPU_HEADER'
#define OS_CPU_HEADER(basename) XSTR(OS_CPU_HEADER_STEM(basename).hpp)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:35:17: note: expanded from macro 'XSTR'
#define XSTR(a) STR(a)
^~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:32:17: note: expanded from macro 'STR'
#define STR(a) #a
^~
<scratch space>:68:1: note: 'globals_bsd_aarch64.hpp' file not found
expanded from here
"globals_bsd_aarch64.hpp"
^~~~~~~~~~~~~~~~~~~~~~~~~
#include OS_CPU_HEADER(globals)
^~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:607:40: note: expanded from macro 'OS_CPU_HEADER'
#define OS_CPU_HEADER(basename) XSTR(OS_CPU_HEADER_STEM(basename).hpp)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:35:17: note: expanded from macro 'XSTR'
#define XSTR(a) STR(a)
^~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:32:17: note: expanded from macro 'STR'
#define STR(a) #a
^~
<scratch space>:68:1: note: expanded from here
"globals_bsd_aarch64.hpp"
^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
1 error generated.
make[3]: *** [/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/hotspot/variant-server/libjvm/gtest/objs/precompiled/precompiled.hpp.pch] Error 1
make[2]: *** [hotspot-server-libs] Error 2
make[2]: *** Waiting for unfinished jobs....
Compiling 405 files for BUILD_jdk.compiler.interim
Compiling 220 files for BUILD_jdk.javadoc.interim
ERROR: Build failed for target 'images' in configuration 'macosx-aarch64-server-release' (exit code 2)
=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.pch:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/precompiled/precompiled.hpp:34:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/classfile/classLoaderData.hpp:30:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/memory/metaspace.hpp:32:
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/runtime/globals.hpp:36:10: fatal error: 'globals_bsd_aarch64.hpp' file not found
#include OS_CPU_HEADER(globals)
^~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:607:40: note: expanded from macro 'OS_CPU_HEADER'
#define OS_CPU_HEADER(basename) XSTR(OS_CPU_HEADER_STEM(basename).hpp)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:35:17: note: expanded from macro 'XSTR'
#define XSTR(a) STR(a)
^~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:32:17: note: expanded from macro 'STR'
#define STR(a) #a
^~
... (rest of output omitted)
* For target hotspot_variant-server_libjvm_objs_precompiled_precompiled.hpp.pch:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/precompiled/precompiled.hpp:34:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/classfile/classLoaderData.hpp:30:
In file included from /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/memory/metaspace.hpp:32:
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/runtime/globals.hpp:36:10: fatal error: 'globals_bsd_aarch64.hpp' file not found
#include OS_CPU_HEADER(globals)
^~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:607:40: note: expanded from macro 'OS_CPU_HEADER'
#define OS_CPU_HEADER(basename) XSTR(OS_CPU_HEADER_STEM(basename).hpp)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:35:17: note: expanded from macro 'XSTR'
#define XSTR(a) STR(a)
^~~~~~
/private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/src/hotspot/share/utilities/macros.hpp:32:17: note: expanded from macro 'STR'
#define STR(a) #a
^~
... (rest of output omitted)
* All command lines available in /private/tmp/openjdk-20200707-29161-7nd6vz/jdk14u-jdk-14.0.1-ga/build/macosx-aarch64-server-release/make-support/failure-logs.
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.
make[1]: *** [main] Error 2
make: *** [images] Error 2
@kortenkamp

This comment has been minimized.

Copy link

@kortenkamp kortenkamp commented Jul 8, 2020

Shouldn't it be possible to compile without hotspot?

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Jul 8, 2020

Shouldn't it be possible to compile without hotspot?

@kortenkamp I think HotSpot is the only Java VM that Oracle ships with their OpenJDK.

@kortenkamp

This comment has been minimized.

Copy link

@kortenkamp kortenkamp commented Jul 8, 2020

Ah ok. But maybe it could help not to create the server variant, but another one… just guessing, sorry.

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Jul 9, 2020

It might be interesting to see if it would be possible to get the C0 interpreter up once libffi patches land, as apparently OpenJDK already supports iOS arm64 builds: http://openjdk.java.net/projects/mobile/ios.html

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Jul 9, 2020

@saagarjha Thanks for the pointer! Will keep it in mind.

@gonzalolarralde

This comment has been minimized.

Copy link

@gonzalolarralde gonzalolarralde commented Jul 15, 2020

If anyone is working on hotspot (not C0) and reaches the point where hardened runtime bypasses don't work and writing to a mmapped address with PROT_WRITE|PROT_EXEC fails with an EXC_BAD_ACCESS despite protections being turned off, this should be a valid workaround until those issues are fixed:

  unsigned long long mask;  
  asm volatile("mrs %0, s3_4_c15_c2_7" : "=r"(mask): :);
  asm volatile("msr s3_4_c15_c2_7, %0" : : "r"(mask & 0xfffffffff0ffffff) :);

kudos to someone in the forums for this piece.

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Jul 15, 2020

Thanks for the info and snippet @gonzalolarralde!

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Jul 15, 2020

You can thank @Siguza for that, I just did a bit of reading :P

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Jul 15, 2020

@saagarjha Nice, I just realized I have that one on my reading list already. I love how small the world is!

@gonzalolarralde

This comment has been minimized.

Copy link

@gonzalolarralde gonzalolarralde commented Jul 15, 2020

@saagarjha ah so it was you, thanks both you and @Siguza then :)

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Jul 19, 2020

I should note that fixing this is actually a bit involved due to the register being thread-local. I have a gist that "works" for multithreaded programs–it will probably fail in complicated cases that aren't using POSIX threads but it is enough to get QEMU off the ground.

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Jul 22, 2020

It might be interesting to see if it would be possible to get the C0 interpreter up once libffi patches land

I believe they have a C0 fork of OpenJDK which appears to be using it for XCode/iTunes/Transporter. My attempts to compile have been unsuccessful so far.

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Jul 25, 2020

I was able to build it successfully, where did your compile fail? If it'd be helpful I'd be glad to share the build artifacts–it "works" well enough for me :P

Edit: it is mind-numbingly slow for anything complicated. But still, it works.

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Jul 27, 2020

I was able to build it successfully, where did your compile fail? If it'd be helpful I'd be glad to share the build artifacts–it "works" well enough for me :P

I had tried to retro-fit the homebrew formula for openjdk14 to point to apple's source (thus making a slow-but-working temporary formula for myself and others). The flags are significantly different though so I figured it needed some coercion.

@fniephaus

This comment has been minimized.

Copy link

@fniephaus fniephaus commented Jul 31, 2020

FWIW I was able to build Apple's OpenJDK14 for macOS 11.0 on a DTK:
https://github.com/apple/openjdk/blob/060f6a31c660e6d8c9dd113b588eb311c61b2fda/build.sh

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Aug 9, 2020

@gonzalolarralde

This comment has been minimized.

Copy link

@gonzalolarralde gonzalolarralde commented Sep 14, 2020

I've kept spending some spare time on this. I've written some hacky patches to make OpenJDK master run and it's currently passing most of the tests (only exception are AOTC-related, I didn't worked on that support). A relevant portion of these patches are just workarounds and shortcuts to get this going on arm64+bsd, but some might become valid patches after reworking them. Reality is that most of the complexity was tracking and fixing some self-inflicted bugs when merging the OS + Arch files. The linux-aarch64 support is very solid and well documented. I'll post in the JEP thread @claui linked earlier here and see if there's anything I can do to collaborate there.

To validate the build I used Jenkins (with --enable-future-java), maven, OpenJDK demos, OpenJDK jtreg + jdk + javalang tests, and DaCapo benchmarks (http://dacapobench.org). I'm not seeing so far any crash or unexpected behavior. It is necessary to mention tho that my tests were very limited.

I'm wondering if it'd make sense to back-port this patches to openjdk@11 and openjdk@14 so they can be early-distributed as a beta using brew. I think it might be valuable to get some of the dependencies running and start trying to uncover package-specific issues while waiting for the final support to land. The most recurrying problem I would expect are native libraries not available as fatfiles or arm64. Any idea / suggestion on how could I distribute a beta like this using brew? It'd be ideal if users could, on request, replace the openjdk counterpart package only for validation purposes.

Most relevant patches are available here: gonzalolarralde/jdk#1
Here is an archived OpenJDK 16 from master, this can be copied to /Library/Java/JavaVirtualMachines/: https://github.com/gonzalolarralde/jdk/releases/tag/v0.0.1-exp

Any feedback / guidance is appreciated!

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Sep 14, 2020

Ooh, very nice! I had this as a low priority thing to check out at some point but I’m glad to see you’ve already done it! I’ll try building it tomorrow and running some Java programs with it, I’m eager to try something that’s not the extremely slow C0…

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Sep 14, 2020

Question: how did you build this? Some derivative of the Apple's build script?

@gonzalolarralde

This comment has been minimized.

Copy link

@gonzalolarralde gonzalolarralde commented Sep 15, 2020

You will need to build JavaNativeFoundation (I got it from apple then changed it to be exported as an static framework to avoid having to distribute it. It’s very lightweight anyway. Then you need to pass the extra LD/c/cpp flags with -F/path/to/your/build

If you want to run tests you will need to pass - -with-jtreg=/path/to/jtreg.

Make sure to check the other branch where the incomplete patches are. Also the bundled image artifact is linked in the thread. Let me know if it’s building fine! Will add instructions tomorrow.

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Oct 10, 2020

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Oct 15, 2020

Seems like beta 10 has tightened signature verification or similar, because mprotect calls are now failing with EINVAL. Perhaps I need to sign with one of the JIT entitlements?

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Oct 15, 2020

mprotect calls are now failing with EINVAL. Perhaps I need to sign with one of the JIT entitlements?

Let’s hope this is just a bug.

Those Beta updates are going in a direction that makes me feel disappointed and uneasy.
Stuff is getting locked down left and right and it’s so difficult to keep up.

@gonzalolarralde

This comment has been minimized.

Copy link

@gonzalolarralde gonzalolarralde commented Oct 17, 2020

@saagarjha ha, thanks for that! it's really not needed after all, as it's currently being used for a very specific feature that relates to motherboards with multiple CPU slots. but still good to know that it is possible

haven't tried beta 10 yet, will try to recompile with it

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Oct 26, 2020

Ok, so a bit more poking makes it seem like there are two problems: MAP_FIXED is just totally broken, and PROT_READ | PROT_WRITE | PROT_EXEC now seems to require MAP_JIT:

$ clang -x c -
#include <stdio.h>
#include <sys/mman.h>

int main() {
	printf("%p\n", mmap((void *)0x1000000, 0x4000, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0));
	printf("%p\n", mmap((void *)0x1000000, 0x4000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0));
	printf("%p\n", mmap((void *)0x1000000, 0x4000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED | MAP_JIT, -1, 0));
	printf("%p\n", mmap(NULL, 0x4000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_JIT, -1, 0));
	printf("%p\n", mmap(NULL, 0x4000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON | MAP_PRIVATE, -1, 0));
}
$ ./a.out
0xffffffffffffffff
0xffffffffffffffff
0xffffffffffffffff
0x10032c000
0xffffffffffffffff

Both are kind of annoying, and I am hoping they are bugs…

@Siguza

This comment has been minimized.

Copy link

@Siguza Siguza commented Oct 26, 2020

@saagarjha you're trying to map inside __PAGEZERO. When loading the main Mach-O for a process, after sliding it, XNU clips the vm_map of the process to start at the lowest segment mapped by the binary, so that no API ever can map anywhere below that.
The unslid base for Mach-Os is usually 0x100000000, so you're way below that.

@gonzalolarralde

This comment has been minimized.

Copy link

@gonzalolarralde gonzalolarralde commented Oct 27, 2020

@saagarjha sadly MAP_FIXED is not allowed to be used together with MAP_JIT for some reason: https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227. I don't think this is considered a bug.

I've opened FB8673407 on Sep 11 but no response on that topic yet, and it seems like they've now restricted mprotect to do RWX so there's no viable way ATM to safely modify the protection of a region that's been reserved in advance and have a guarantee to obtain the same address as requested.

It still escapes to my understanding what would be the reason for that being explicitly disabled, as what MAP_FIXED is supposed to do is to deallocate and remap atomically as it says here: https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L482-L492

In any case, as all the accesses to mmap are centralized in os_bsd, it might still be possible to have a region-based lock to try to emulate. this behavior, although I'm not sure of the reliability of this method.

@saagarjha

This comment has been minimized.

Copy link

@saagarjha saagarjha commented Oct 29, 2020

Ah yes, of course, I forgot that arm64 brings up the zero page…🤦 MAP_FIXED and MAP_JIT are incompatible for some reason, yes. I have no idea why, but this is just something that we'll need to deal with. For what it's worth, I found that there are other people working on this: https://github.com/openjdk/jdk-sandbox/tree/JEP-391-branch. I haven't tried building it yet, but their patch mprotects before mmaping–it's clever but I thought this didn't work on macOS, so I guess I'll run some tests tomorrow to see what is actually going on here.

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Nov 16, 2020

GOOD NEWS, EVERYONE!

Looks like the JEP-319 folks are getting there!

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 16, 2020

@claui, I'm very excited to try this out. Microsoft has a download available here which builds from that branch. https://github.com/microsoft/openjdk-aarch64/releases/download/16-ea%2B10-macos/jdk-16-ea+10-macos+aarch64.tar.gz. I haven't taken a swing at a brew recipe, just yet. If someone beats me to this, please share.

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Nov 16, 2020

@tresf Thanks for the link, will share here if I get around to writing the formula!

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 16, 2020

@claui, slightly off-topic, but I don't want to clutter the original thread...

We’re not going to support native ARM Homebrew installations because we don’t have an Apple-Silicon-based CI infrastructure yet.

Is there anything the community can do to help with this effort? e.g. https://github.com/homebrew/brew#donations or is this more of a limitation to existing CI infrastructure that can only occur with time? I ask because I donated two arm64 machines to the AdoptOpenJDK team (the same team that works for Microsoft Azure and are providing these download links) so that they could add it their Windows build infrastructure. Is Homebrew interested in a similar stop-gap procurement or perhaps more broadly, will Homebrew need additional donations to help this effort at large? (feel free to quote/cross-post in whole or in part if it's relevant to the original Apple SI bug report).

@claui

This comment has been minimized.

Copy link
Owner Author

@claui claui commented Nov 18, 2020

Tres, thank you so much for your generous offer. 🍻

I’ve checked with @MikeMcQuaid, the project lead, who has been making arrangements with Apple and our hosting provider. The good news is we’re going to have a decent amount of Apple Silicon Macs, which will help us bootstrap and support our CI.

That means we’re no longer short of devices. We may be able to start building binary bottles for Apple Silicon within weeks rather than months.

So it looks like the bottleneck (no pun intended) is going to be getting popular formulae such as gcc or cabal-install running natively on Apple Silicon.

Right now we appreciate volunteers who help fix broken formulae or report working formulae on Homebrew/brew#7857.
Donations are welcome, too.
Thank you folks for everything you’re doing to help make this fly!

@VladimirKempik

This comment has been minimized.

Copy link

@VladimirKempik VladimirKempik commented Nov 21, 2020

if you want to build our jep-391 preview branch then use these configure arguments (assuming it's done on intel mac with Xcode12):

sh configure --with-boot-jdk=/path/to/some/jdk15_or16ea/for/intel --with-build-jdk=/path/to/openjdk16ea/build/for/intel --with-debug-level=release --disable-warnings-as-errors --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' --with-extra-ldflags='-arch arm64 -F/path/to/Xcode.app//Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/' --with-extra-cxxflags='-arch arm64'

make images

then copy JavaNativeFoundation.framework to $JAVA_HOME/lib/

p.s. build-jdk better be exact same version as the one you trying to build

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 21, 2020

@VladimirKempik, thanks so much for sharing, this gist doesn't allow 👍 / ❤️ reactions, so I have to type them out. :)

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 24, 2020

@VladimirKempik, XCode 12.2 shows the following error building with your steps. I assume this has something to do with the version of the JavaNativeFoundation.tbd. Do you know if this updated with a particular XCode version? This post suggest that it may be intentionally removed, but I recall this being missing from Microsoft's build and specifically mentioned in yours, so I assume it's needed. Any advice?

Note, I'm NOT on the beta version of Xcode.

ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/JavaNativeFoundation.framework/JavaNativeFoundation.tbd, missing required architecture arm64 in file /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/JavaNativeFoundation.framework/JavaNativeFoundation.tbd
Undefined symbols for architecture arm64:
  "_JNFCallVoidMethod", referenced from:
      _Java_apple_security_KeychainStore__1scanKeychain in KeystoreImpl.o
  "_JNFJavaToNSString", referenced from:
      _Java_apple_security_KeychainStore__1addItemToKeychain in KeystoreImpl.o
  "_JNFNativeMethodEnter", referenced from:
      _Java_apple_security_KeychainStore__1addItemToKeychain in KeystoreImpl.o
  "_JNFNativeMethodExit", referenced from:
      _Java_apple_security_KeychainStore__1addItemToKeychain in KeystoreImpl.o
  "_OBJC_CLASS_$_JNFException", referenced from:
      objc-class-ref in KeystoreImpl.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

Hmm... after digging it appears Apple moved to an open-source version that's intended to be built with openjdk. Does openjdk plan to eventually bundle this source like apple's openjdk does?

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

While I await a stance from openjdk on bundling the JavaNativeFoundation.framework, I've created a stop-gap by compiling it myself and zipping it up.

https://github.com/tresf/homebrew-tresf/blob/main/Formula/openjdk.rb

This formula points at the last commit in JEP-391 sandbox. (At the time of writing this, a56ddad).

brew tap tresf/tresf
brew install tresf/tresf/openjdk

What I have now is a mostly operational openjdk@16, however something's gravely wrong with it.

  • jarsigner completely bombs out, returning 137 each time
  • java -jar always shows the following error:
    • zsh: zsh: killed
    • bash: Killed: 9

What's even stranger is, when I run it from debug, e.g.:

lldb java
run java -jar /path/to/my.jar

It too crashes, but the program starts up just fine. Well, not "fine" -- there are some of my own bugs to sort -- but the app actually starts. How is this possible? Why would a binary start from lldb but not from terminal?

(lldb) run -jar out/dist/qz-tray.jar
Process 60637 launched: '/opt/homebrew/opt/openjdk/bin/java' (arm64)
zsh: killed     lldb /opt/homebrew/opt/openjdk/bin/java

What's happening? Does /opt/homebrew/opt/openjdk/bin/java have some process wrapper under the covers? How do I find out what the underlying errors actually are? Help appreciated.

The Java project I'm testing with is on GitHub. I can provide a link if someone's interested, but I feel these issues will exist for any Java project.

@VladimirKempik

This comment has been minimized.

Copy link

@VladimirKempik VladimirKempik commented Nov 25, 2020

zsh: killed

Big sur has issues with caching signature checks when one overwrites (e.g. with cp) an executable file,
you have two options:

  1. reboot the host
  2. fixup script:
    cp $a $b
    rm $a
    mv $b $a
    but since you don't know which exactly binary/dylib has issue, better to do it with whole built jdk.

this will force the kernel to update signature cache.

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

Thanks. lldb finally told me to look at the Console.app application, which confirms the suspicion that this is a bad or cached signature. It may be that JavaNativeFoundation I built earlier, but I'm confused how to fix it.

Neither rebooting nor copying the directory fixed it (yet). Note, Homebrew seems to have some automatic handling of the copying you're talking about here: https://github.com/Homebrew/brew/blob/e945b1c42ab44feb1c6814f47cc833d76b1a921c/Library/Homebrew/os/mac/keg.rb#L42, so I was hoping this problem would not crop up.

I'll dig a bit deeper, thanks for the pointer, hopefully it's simple once I figure it out.

Exception Type:        EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes:       0x0000000000000032, 0x0000000103050000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x2

kernel messages:

VM Regions Near 0x103050000:
    __LINKEDIT                  103048000-103050000    [   32K] r--/rwx SM=COW  /opt/homebrew/*/*.dylib
--> mapped file                 103050000-103054000    [   16K] r--/r-x SM=PRV  Object_id=9c24063d
    MALLOC_TINY                 103100000-103200000    [ 1024K] rw-/rwx SM=PRV  

Application Specific Information:
dyld: in dlopen()
@rpath/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation

When I try to self-sign the offending file, it complains with this:

/opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation: replacing existing signature
/opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation: code object is not signed at all
In subcomponent: /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation.tbd
@VladimirKempik

This comment has been minimized.

Copy link

@VladimirKempik VladimirKempik commented Nov 25, 2020

As I first step I would try JNF.framework form Xcode12.2 which can be found in folder /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/

then just replace binary and Info.plist inside and resign the framework.

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

Ok, I got it. Man this is painful. I'm not sure how to handle this long term, this JavaNativeFoundation.framework will need to be built and bundled.

cp -R /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework2

rm -rf /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework

mv /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework2 /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework

codesign --remove-signature /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework

codesign --sign - --deep /opt/homebrew/Cellar/openjdk/16/libexec/openjdk.jdk/Contents/Home/lib/JavaNativeFoundation.framework
@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

As I first step I would try JNF.framework form Xcode12.2 which can be found in folder /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/

Yeah, I guess that works. I didn't think of that because it's missing the .tbd file. Do you know if Apple's going to ship it with a future version of XCode? I don't really understand why they leave the aarch64 support out.

@VladimirKempik

This comment has been minimized.

Copy link

@VladimirKempik VladimirKempik commented Nov 25, 2020

I doubt they will change anything regarding JNF.framework
You don't need tbd file in your own version of JNF. it's only used by linker, but if the binary of library is present (in your case it's present), linker can use the library instead of tbd file just fine.

I personally prefer to link with Xcode library from their java and then copy my own version of JNF into $JAVA_HOME/lib. The least painful way IMO.

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

I personally prefer to link with Xcode library from their java and then copy my own version of JNF into $JAVA_HOME/lib. The least painful way IMO.

I'm fine with that too. I'll try that. Thanks for the info on the .tbd being optional. Based on the failure logs, I thought it was needed. Using their version saves the mess, I'll take a second swing at that later, thanks.

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

Ok, Homebrew is trying to update the JavaNativeFoundation signature with an adhoc one and it's somehow breaking the binaries from the system after copy. Right now, I have it in the install step. If I delete those Homebrew copied and copy the system ones, the issue goes away. @claui or any others familiar with formula, Is there a postinstall step or a way to exclude certain files from being signed?

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

... found post_install in another formula. Trying that.... 🤞

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Nov 25, 2020

I think the formula is in good shape, will bring my questions over to Homebrew/brew#7857.

@tresf

This comment has been minimized.

Copy link

@tresf tresf commented Dec 1, 2020

Just an update, there's an openjdk.rb PR with some active discussion here: Homebrew/homebrew-core#65670. The current conversation is surrounding how to provide JEP-391 conditionally on arm for Homebrew. Until it's accepted, I do have a tap available over at tresf/test that will build using the sandbox JEP-391 branch and @VladimirKempik's kindly provided instructions.

I'll be continuing all discussions over at Homebrew/homebrew-core#65670.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment