Hello Renamed the bug to "Fix issues with cross-compile on macos"
Please check updated webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ <http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/> Adlc is fine with cross-compiling now. Regards, Vladimir > 10 авг. 2020 г., в 12:52, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > написал(а): > > So, basically, what this patch is about is not so much "preparation for > aarch64" as "allow cross-compile on macos"? If I understand you correctly, > maybe you should rename the bug? > > /Magnus > > On 2020-08-04 16:09, Erik Joelsson wrote: >> That's a good find! You are correct in that we haven't cross compiled in any >> direction involving Macosx before. >> >> The preferred patch would be a bit more elaborate than that. Ideally we need >> better control over the toolchain type of the BUILD_* compiler settings. For >> now, I think just forcing clang/clang++ if BUILD_OS is macosx is good enough. >> >> /Erik >> >> On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >>> 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.
