Wheel for AArch64

[todorkolev]

Feature Request

Problem Statement

I want to use Nautilus in a dev container on a MacBook with ARM (M3) processor. The container uses linux/aarch64 architecture and since there is no wheel for this architecture, it builds from source. The actual problem is that this build fails.

Proposed Solution

Best solution will be if there is a precompiled PyPI package available for linux/aarch64.

Alternatives Considered

I tried building the nautilus_trader.dockerfile from the v1.214.0 tag on my ARM MacBook and it fails with a series of undefined reference errors. Here is the end of the output:

...
          /usr/bin/ld: /opt/pysetup/target/release/deps/to_json-6e54bd2d7b7b8bcc.to_json.8038b72eb63d3d26-cgu.0.rcgu.o:(.data.rel.ro..Lswitch.table._ZN14nautilus_model6python6orders10stop_limit68_$LT$impl$u20$nautilus_model..orders..stop_limit..StopLimitOrder$GT$27__pymethod_get_py_is_open__17heeb3ca1bdc1b45daE+0x10): undefined reference to `_Py_FalseStruct'
          /usr/bin/ld: /opt/pysetup/target/release/deps/to_json-6e54bd2d7b7b8bcc.to_json.8038b72eb63d3d26-cgu.0.rcgu.o:(.data.rel.ro..Lswitch.table._ZN14nautilus_model6python6orders10stop_limit68_$LT$impl$u20$nautilus_model..orders..stop_limit..StopLimitOrder$GT$27__pymethod_get_py_is_open__17heeb3ca1bdc1b45daE+0x18): undefined reference to `_Py_FalseStruct'
          /usr/bin/ld: /opt/pysetup/target/release/deps/to_json-6e54bd2d7b7b8bcc.to_json.8038b72eb63d3d26-cgu.0.rcgu.o:(.data.rel.ro..Lswitch.table._ZN14nautilus_model6python6orders10stop_limit68_$LT$impl$u20$nautilus_model..orders..stop_limit..StopLimitOrder$GT$27__pymethod_get_py_is_open__17heeb3ca1bdc1b45daE+0x20): undefined reference to `_Py_TrueStruct'
          /usr/bin/ld: /opt/pysetup/target/release/deps/to_json-6e54bd2d7b7b8bcc.to_json.8038b72eb63d3d26-cgu.0.rcgu.o:(.data.rel.ro..Lswitch.table._ZN14nautilus_model6python6orders10stop_limit68_$LT$impl$u20$nautilus_model..orders..stop_limit..StopLimitOrder$GT$27__pymethod_get_py_is_open__17heeb3ca1bdc1b45daE+0x28): undefined reference to `_Py_TrueStruct'
          /usr/bin/ld: /opt/pysetup/target/release/deps/to_json-6e54bd2d7b7b8bcc.to_json.8038b72eb63d3d26-cgu.0.rcgu.o:(.data.rel.ro..Lswitch.table._ZN14nautilus_model6python6orders10stop_limit68_$LT$impl$u20$nautilus_model..orders..stop_limit..StopLimitOrder$GT$27__pymethod_get_py_is_open__17heeb3ca1bdc1b45daE+0x30): undefined reference to `_Py_TrueStruct'
          /usr/bin/ld: /opt/pysetup/target/release/deps/to_json-6e54bd2d7b7b8bcc.to_json.8038b72eb63d3d26-cgu.0.rcgu.o:(.data.rel.ro..Lswitch.table._ZN14nautilus_model6python6orders10stop_limit68_$LT$impl$u20$nautilus_model..orders..stop_limit..StopLimitOrder$GT$27__pymethod_get_py_is_open__17heeb3ca1bdc1b45daE+0x38): undefined reference to `_Py_TrueStruct'
          clang: error: linker command failed with exit code 1 (use -v to see invocation)
          
  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)

error: could not compile `nautilus-persistence` (bin "to_json") due to 1 previous error

[cjdsellers]

Hi @todorkolev

This looks like it might be an environment issue. One of my machines is also a MacBook with an ARM processor. Ensure you have shared objects enabled with a Python dev installation for the Python.h to be available.

Also ensure you have the LD_LIBRARY_PATH env var set to the lib dir of whichever Python is running the build. It would look something like:

/home/chris/.local/share/uv/python/cpython-3.12.9-linux-x86_64-gnu/lib

Further clues in this CI workflow.

Separately, I agree that a linux/aarch64 binary wheel would be useful. This just needs to be set up in CI, although one caveat is that this will produce an additional 2-3 wheels every release (depending on how many Python versions are supported). Since the binary wheels are so large, this means there will be less lookback window for releases on PyPI (there is a project limit of 10 GB, and difficult to request more).

A wheel could still be made available in the Nautech Systems package index though without this limitation.

[faysou]

You can easily compile and install nautilus using one of the gists in the link below, either with a pyenv or uv venv. pyenv venv is compatible with debugging in intellijidea.

This way it doesn't matter which wheel exists and you also have access to the latest updates on the develop branch.

https://gist.github.com/faysou

[todorkolev]

Thanks for the replies, @cjdsellers, @faysou!

Your instructions seem to be about setting up a local build on the MacOS itself. This is not what I'm trying to do. My goal is to build and run Nautilus inside a Linux container on a MacBook ARM machine. Simply building nautilus_trader.dockerfile on an ARM MacBook results in the undefined reference errors on the cargo build step.

I need to run a linux/aarch64 container because I expect my project to be deployed also on an ARM server. These servers are becoming mainstream already.

[binary-signal]

Hi @todorkolev

This looks like it might be an environment issue. One of my machines is also a MacBook with an ARM processor. Ensure you have shared objects enabled with a Python dev installation for the Python.h to be available.

Also ensure you have the LD_LIBRARY_PATH env var set to the lib dir of whichever Python is running the build. It would look something like:

/home/chris/.local/share/uv/python/cpython-3.12.9-linux-x86_64-gnu/lib

Further clues in this CI workflow.

Separately, I agree that a linux/aarch64 binary wheel would be useful. This just needs to be set up in CI, although one caveat is that this will produce an additional 2-3 wheels every release (depending on how many Python versions are supported). Since the binary wheels are so large, this means there will be less lookback window for releases on PyPI (there is a project limit of 10 GB, and difficult to request more).

A wheel could still be made available in the Nautech Systems package index though without this limitation.

To exclude one of the suggested options python docker images have --enabled-shared flag enabled

Reference Docker file https://github.com/docker-library/python/blob/dca0bacef603d05737683ac063f81037db7a5203/3.12/slim-bookworm/Dockerfile#L77

[cjdsellers]

Support for linux/aarch64 wheels has been added from commit https://github.com/nautechsystems/nautilus_trader/commit/b27914a09a08ff97e7ccde8c4967c3064d12f419.

Development wheels for this platform are built from the nightly branch and published to our private package index.

Furthermore, linux/aarch64 will be officially supported, with binary wheels included in each release published to both our private package index and PyPI.

[swapniel99]

Hi. I am still getting "manifest unknown" while doing this. I am using --platform linux/aarch64 in build command. Am I doing anything wrong?

docker build --build-arg GIT_TAG=$(GIT_TAG) -f .docker/jupyterlab.dockerfile --platform linux/aarch64 -t $(IMAGE):jupyter .