[SERVER-50115] arm64/aarch64 support for macOS Created: 05/Aug/20  Updated: 29/Oct/23  Resolved: 02/Apr/22

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: 4.4.0
Fix Version/s: 6.0.0-rc0

Type: Improvement Priority: Minor - P4
Reporter: Ryan Schmidt Assignee: Andrew Morrow (Inactive)
Resolution: Fixed Votes: 14
Labels: platform-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-64295 Enable jstests in macOS ARM64 configu... Closed
depends on SERVER-42427 Upgrade MozJS/Spidermonkey to ESR 91 Closed
depends on SERVER-47276 Evaluate upgrade of Spidermonkey to E... Closed
depends on SERVER-61008 Upgrade MozJS Closed
is depended on by SERVER-56782 Reintroduce advanced microarchitectur... Closed
is depended on by SERVER-64543 Build Stitch Support Lib on macOS arm64 Closed
Duplicate
Related
related to MONGOSH-442 What do we need to do to support for ... Closed
related to MONGOSH-773 What do we need to do to support home... Closed
Backwards Compatibility: Fully Compatible
Sprint: Dev Platform 2022-04-04
Participants:

 Description   

Looks like mongodb 4.4.0 supports x86_64 on Linux and macOS, and arm64/aarch64 on Linux but not yet on macOS; I get this error:

<built-in>:1:10: fatal error: 'js-confdefs.h' file not found
#include "js-confdefs.h"
 ^~~~~~~~~~~~~~~

I see lots of js-confdefs.h files, just not in an aarch64/macOS directory:

% find . -name js-confdefs.h
./src/third_party/mozjs-60/platform/ppc64le/linux/build/js-confdefs.h
./src/third_party/mozjs-60/platform/s390x/linux/build/js-confdefs.h
./src/third_party/mozjs-60/platform/aarch64/linux/build/js-confdefs.h
./src/third_party/mozjs-60/platform/x86_64/macOS/build/js-confdefs.h
./src/third_party/mozjs-60/platform/x86_64/freebsd/build/js-confdefs.h
./src/third_party/mozjs-60/platform/x86_64/linux/build/js-confdefs.h
./src/third_party/mozjs-60/platform/x86_64/windows/build/js-confdefs.h

So we need to add a ./src/third_party/mozjs-60/platform/aarch64/macOS directory with all of its contents. I can try to do it, if you'll let me know how the existing directories were created.



 Comments   
Comment by Githook User [ 01/Apr/22 ]

Author:

{'name': 'Andrew Morrow', 'email': 'acm@mongodb.com', 'username': 'acmorrow'}

Message: SERVER-50115 SERVER-64543 Add macOS arm release builders
Branch: master
https://github.com/mongodb/mongo/commit/362859101de94cf094ae82e6b029b9a22d0d3bd5

Comment by Anna Henningsen [ 16/Mar/22 ]

This is marked as blocked, but all dependency tickets are closed. Is this still blocked at this point?

Comment by Andrew Morrow (Inactive) [ 18/Jul/21 ]

ryandesign - We are still waiting on an ESR release from Mozilla that contains Apple Silicon support, after which we will need to do the work to upgrade to the new release. That work is being tracked in SERVER-42427, on which this ticket is blocked.

Comment by Ryan Schmidt [ 18/Jul/21 ]

Was this supposed to have been fixed in 5.0.0? When I try to build 5.0.0 on Apple Silicon without --js-engine=none I get:

scons: *** [build/XXX/mongo/scripting/mozjs/countdownlatch.o] AttributeError : 'NoneType' object has no attribute 'disambiguate'
scons: building terminated because of errors.

With --js-engine=none it builds, as did 4.x.

Comment by Andrew Morrow (Inactive) [ 19/Aug/20 ]

ryandesign - I created the configurations, however, MozJS does not seem to build out of the box, failing somewhere inside WASM support. This suggests that full MacOS ARM support is going to require an upgrade to a MozJS ESR release that supports MacOS ARM. In the meantime, you can build with --js-engine=none to work around this. This will, however, mean that the resulting mongod binary has no $where or other JS based feature support, and the mongo shell won't exist at all.

Comment by Andrew Morrow (Inactive) [ 19/Aug/20 ]

ryandesign - I managed to get it working after grubbing around in some Mozilla bug reports like https://bugzilla.mozilla.org/show_bug.cgi?id=1588340. I added --disable-shared-js to the configure invocation and that seems to have fixed it. What I can't explain is how we managed to generate the existing macOS x86_64 configurations without that. I checked out the original commit where we added ESR 60 and it still didn't work without that flag. The only thing I can figure is that it is something environmental based on running on a newer macOS version. In any event, I have the configs generated and will get them reviewed and committed. Whether the generated JS integration actually functions is another question entirely.

Comment by Andrew Morrow (Inactive) [ 19/Aug/20 ]

ryandesign -

I was surprised to hear that the build scripts created a virtualenv - a little digging reveals that it seems to be within one of Mozilla's own build scripts. That is a hassle, as of course is Apple's behavior here: breaking virtualenv is ... a little extreme. So that precludes, at least temporarily, doing a native build.

Regarding the attempts to do this on an Intel mac, I don't think we have ever tried to use the MozJS configure process in a cross-compilation setting. It probably was never considered necessary and never attempted. I think your observation that we are saying --host when we ought to be saying --target is likely correct, assuming that the configure script is sane.

I don't happen to know what that error you received is about. It is quite obscure. I will try it locally and get back to you.

Comment by Ryan Schmidt [ 06/Aug/20 ]

Thanks for the pointers. Sounds straightforward enough. Here's where I've got to so far.

I added these lines to the case statement in gen-config.sh:

    "platform/aarch64/macOS")
        _xcode_setup "macosx" "arm64" "macos-version-min=11.0"
        _CONFIG_OPTS="--target=aarch64-apple-darwin"
        ;;

I didn't get very far trying to run the script on an ARM Mac. I ran ./gen-config.sh aarch64 macOS but the build process creates a virtualenv and that fails:

ERROR: virtualenv is not compatible with this system or executable

Apparently creating a virtualenv copies the system's python executable – which was compiled arm64e – into the virtualenv, at which point it's not a blessed system executable anymore; it's just a regular user executable which isn't allowed to be arm64e, so the copied python doesn't work.

I switched over to an Intel Mac and got further, but it soon failed with:

Traceback (most recent call last):
  File "./../../configure.py", line 127, in <module>
    sys.exit(main(sys.argv))
  File "./../../configure.py", line 34, in main
    return config_status(config)
  File "./../../configure.py", line 122, in config_status
    return config_status(args=[], **encode(sanitized_config, encoding))
  File "/Users/rschmidt/mongodb-src-r4.4.0/src/third_party/mozjs-60/mozilla-release/python/mozbuild/mozbuild/config_status.py", line 144, in config_status
    definitions = list(definitions)
  File "/Users/rschmidt/mongodb-src-r4.4.0/src/third_party/mozjs-60/mozilla-release/python/mozbuild/mozbuild/frontend/emitter.py", line 195, in emit
    objs = list(self._emit_libs_derived(contexts))
  File "/Users/rschmidt/mongodb-src-r4.4.0/src/third_party/mozjs-60/mozilla-release/python/mozbuild/mozbuild/frontend/emitter.py", line 285, in _emit_libs_derived
    contexts[lib.objdir])
mozbuild.frontend.reader.SandboxValidationError:
==============================
FATAL ERROR PROCESSING MOZBUILD FILE
==============================

The error occurred while processing the following file or one of the files it includes:

    /Users/rschmidt/mongodb-src-r4.4.0/src/third_party/mozjs-60/mozilla-release/js/src/build/moz.build

The error occurred when validating the result of the execution. The reported error is:

    The static "js" library is not used in a shared library or a program, but USE_LIBS contains the following shared library names:
        mozglue

    Maybe you can remove the static "js" library?

Have you seen this error before or know what it's talking about? The error is the same if I try to ./gen-config.sh x86_64 macOS without my modifications, even on an older system running macOS 10.13, so it appears just to be broken somehow.

P.S: Shouldn't the places where gen-config.sh is using --host in _CONFIG_OPTS be using --target instead?

Comment by Andrew Morrow (Inactive) [ 05/Aug/20 ]

Hi ryandesign -

As of right now, macOS on ARM is not a supported platform for MongoDB v4.4, or any other stable MongoDB release. We are in the process of finalizing the platform roadmap for future releases. That proposed roadmap currently includes an investigation into supporting macOS on ARM, and includes backporting any such support to at least v4.4, if possible.

Given that, it is interesting to note that the current r4.4.0 sources largely build without modification on the macOS ARM platform, with the exception of SpiderMonkey, for which we do not yet have the necessary platform configuration files, as you have discovered.

Producing those files isn't straightforward, and we have not yet investigated whether the vendored version of SpiderMonkey even builds or works on macOS ARM. If not, then adding support for macOS on ARM will require upgrading to a version of SpiderMonkey which does, which is a significant undertaking. There may not even be such a version, yet.

Meanwhile, you can build the majority of the tree by using the flag --js-engine=none, which will disable JavaScript entirely. This will of course mean that you don't get a binary for the mongo shell, which is inherently JS based.

Finally, I'll note here a few important caveats and other pieces of information that may be helpful while experimenting with building the tree for macOS ARM:

  • For the most part, the SCons build ignores the shell environment from which it is invoked, but on macOS we make an exception and do honor DEVELOPER_DIR if it is set. So if you have Xcode in a non-standard location, you can say {{DEVELOPER_DIR=/Path/To/Xcode-beta.app scons ... }} and it will do the right thing.
  • With Xcode 12, some new warnings are produced and by default the server build promotes warnings to errors. You can work around this by building with --disable-warnings-as-errors.
  • As noted above, JavaScript support via SpiderMonkey does not yet work, but you can disable it with --js-engine=none. No mongo shell will be produced.
  • It is possible to cross compile to macOS ARM on an x86_64 macOS machine with the current build system, by setting CCFLAGS and LINKFLAGS, either on your scons command line or in a SCons Variables file. Something like DEVELOPER_DIR=/Path/To/Xcode-beta.app scons ... --variables-files=etc/scons/xcode_macosx.vars ... CCFLAGS="-isysroot $(DEVELOPER_DIR=/Path/To/Xcode-beta.app xcrun --sdk macosx --show-sdk-path) -mmacosx-version-min=11.0 -arch arm64" LINKFLAGS="-Wl,-syslibroot,$(DEVELOPER_DIR=/Path/To/Xcode-beta.app xcrun --sdk macosx --show-sdk-path) -mmacosx-version-min=11.0 -arch arm64" ...
  • It is not currently possible to do a single build targeting both architectures (i.e. -arch x86_64 -arch arm64). The builds must be produced separately and then fused with lipo.
  • Some small changes are probably required to ensure that hardware accelerated crc32 is are used when targeting macOS ARM. Support for hardware accelerated crc32 on ARM is available in the tree, but is currently only enabled for Linux. Without this change support will fall back to a software implementation.
  • It is possible to target arm64e rather than arm64, but such binaries apparently do not run on the available hardware without enabling the preview arm64e ABI (see https://developer.apple.com/forums/thread/652340), which we have not attempted.

Regarding your specific question about how to generate the configurations for MozJS: you can see this thread from a while back about how to go about it: https://groups.google.com/g/mongodb-dev/c/G-kGjZEEam0/m/VSVB9fYCBAAJ. Obviously some versions have changed, but the general procedure has not. Overall, this all depends on how well the MozJS ESR 60 release happens to do when targeting macOS and ARM simultaneously. If you are interested in trying it out we are of course interested in any results you obtain. Otherwise, this will be one of the first things we pick up if and when we officially start our efforts to target macOS on ARM.

Please let us know if there is anything else we can do to help.

Generated at Thu Feb 08 05:21:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.