Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system.
Being a cross-compile, we therefore hit this case: https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 And thus infers `/usr/bin/CC` for CXX. I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: --- a/make/autoconf/toolchain.m4 +++ b/make/autoconf/toolchain.m4 @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], # find the build compilers in the tools dir, if needed. UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) UTIL_FIXUP_EXECUTABLE(BUILD_CC) - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) UTIL_FIXUP_EXECUTABLE(BUILD_CXX) UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) UTIL_FIXUP_EXECUTABLE(BUILD_NM) Although I'm not sure about its cleanliness :-) -Bernhard ________________________________________ From: build-dev <build-dev-r...@openjdk.java.net> on behalf of David Holmes <david.hol...@oracle.com> Sent: Tuesday, August 4, 2020 00:46 To: Erik Joelsson; Vladimir Kempik; build-dev Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 On 3/08/2020 10:57 pm, Erik Joelsson wrote: > Hello Vladimir, > > These changes look innocent enough to me. They aren't actually adding > macosx-aarch64 support, they are just removing two minor (and more > likely OS version related) hurdles from the build. You still have to > provide the actual configuration on the configure command line as is > shown in your example. Before we can call build system support, we would > need configure to automatically setup those flags and add a separate > parameter for the JNF framework. So, given that, I don't think this > change warrants a JEP in itself. Of course this change doesn't warrant a JEP in itself :) My point is that until we have a JEP for the platform that is being targeted then we shouldn't be making changes to provide support for that platform. That said I didn't actually look at the changes but focused on the larger stated aim, so apologies for that. The actual changes here are small and not obviously related to supporting macOS-Aarch64. But I'm unclear on this change as it affects all macOS builds: 42 else ifeq ($(call isBuildOs, macosx), true) 43 ADLC_LDFLAGS := -lc++ if this was fixing a bug as indicated, why do we not see this bug in regular builds? Thanks, David ----- > My only complaint is that you revert jib-profiles.js. That file is only > used internally at Oracle. If/when we need it to support macosx-aarch64, > we will provide those changes. > > I must say I'm happy to see you managed to get a working build > configuration with just this though! > > /Erik > > On 2020-08-01 00:24, Vladimir Kempik wrote: >> Hello >> >> Please review this change for JDK-8250876 >> >> This changeset adds support for macos/aarch64 into build system. >> It will allow to crosscompile for macos/aarch64 using intel mac as well. >> >> This changeset does NOT address some arm specific issues in the macos >> related code, we plan to do that in s separate commit. >> >> An example of configure to cross-compile for macos/arm64: >> >> --with-boot-jdk=/path/to/java/ >> --with-build-jdk=/path/to/same/java/as/compiled >> --disable-warnings-as-errors --with-jvm-variants=zero >> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >> arm64' --with-extra-ldflags='-arch arm64 >> -F/Path/To/Folder/Containing/JNF_framework/' >> —with-extra-cxxflags='-arch arm64’ >> >> JNF.framework is missing arm64 part as of next macos release, but >> Apple has opensourced it. >> >> Fix to adlc were needed due to it using symbols from stdc++ and not >> linking to it, so it fails when doing make images. >> >> The webrev: >> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >> The bug: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >> >> Testing: jdk/submit. >> >> Thanks, Vladimir.
