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.
