RFR: 8250876: Build system preparation to macos on aarch64

[Bernhard Urban-Forster]

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-retn at openjdk.java.net> on behalf of David Holmes <david.holmes at 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.