Docker image for linux/arm64/v8

[mdtanrikulu]

Currently the docker build image is based on linux/amd64 architecture, thus makes the the terminal complains with new M1 machines. It would be better to have a way or guide for new M1 macs, if there is anything more/different needed.

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

P.S.: This is just a warning in terminal, apart from that everything seems fine.

[rth]

Indeed it could have been nice to investigate if building on arm64/v8 works.

A first step would be to build the docker image we use locally on ARM machine. The pre-built binaries for browsers would likely need to be installed from different URLs for ARM.

docker build -t iodide/pyodide-env:12 .

where the tag needs to match one used in run_docker.

Then build packages in this docker image.
I suspect at least a few architecture dependent fixes would be necessary (e.g. here.

Though after all that work, I'm not sure how much faster native arm64 images would be. It would still run a VM with qemu on Mac M1 as far as I understand.

[mdtanrikulu]

Oh I should update docker to the rc3 then. Not sure if my version is using qemu, but seems they made it default on newest version. Thanks for the information in general. For future this issue might be beneficial as a reminder about M1 native support if docker also completes it's own experimental virtualization option.

[grimmer0125]

https://docs.docker.com/desktop/mac/apple-silicon/ is in GA stage and I already used it for a while and feels good.

[thadk]

When trying to use an arm64-built version of pyodide-env 20, I had to comment out the official Chrome download in the Dockerfile because you'd have to use Chromium-arm64 instead I think, but I got as far as this on arm64. It does seem much snappier. The issue below seems like could be in emsdk?:

➜ ./run_docker
thadk@33367d8d87ea:/src$ PYODIDE_PACKAGES="..." make
./tools/dependency-check.sh
date +"[%F %T] Building emsdk..."
[2022-07-01 08:05:09] Building emsdk...
make -C emsdk
make[1]: Entering directory '/src/emsdk'
if [ -d emsdk ]; then rm -rf emsdk; fi
git clone --depth 1 https://github.com/emscripten-core/emsdk.git
Cloning into 'emsdk'...
remote: Enumerating objects: 82, done.
remote: Counting objects: 100% (82/82), done.
remote: Compressing objects: 100% (73/73), done.
remote: Total 82 (delta 7), reused 38 (delta 4), pack-reused 0
Unpacking objects: 100% (82/82), done.
cd emsdk && ./emsdk install --build=Release 3.1.14
Resolving SDK version '3.1.14' to 'sdk-releases-upstream-ade9d780ff17c88d81aa13860361743e3c1e1396-64bit'
Installing SDK 'sdk-releases-upstream-ade9d780ff17c88d81aa13860361743e3c1e1396-64bit'..
Installing tool 'node-14.18.2-64bit'..
Downloading: /src/emsdk/emsdk/zips/node-v14.18.2-linux-arm64.tar.xz from https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/node-v14.18.2-linux-arm64.tar.xz, 21134636 Bytes
Unpacking '/src/emsdk/emsdk/zips/node-v14.18.2-linux-arm64.tar.xz' to '/src/emsdk/emsdk/node/14.18.2_64bit'
Done installing tool 'node-14.18.2-64bit'.
Installing tool 'releases-upstream-ade9d780ff17c88d81aa13860361743e3c1e1396-64bit'..
Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/ade9d780ff17c88d81aa13860361743e3c1e1396/wasm-binaries-arm64.tbz2': HTTP Error 404: Not Found
error: installation failed!
make[1]: *** [Makefile:9: emsdk/.complete] Error 1
make[1]: Leaving directory '/src/emsdk'
make: *** [Makefile:232: emsdk/emsdk/.complete] Error

I think this is the index that wasm-binaries-arm64.tbz2 should appear on. Maybe it is inappropriately appending -arm64 since there is no wasm-binaries-amd64.tbz2 file. Here: https://github.com/emscripten-core/emsdk/blob/3e7e0ab8c352786fa5b799845f16627eb35a9f89/emsdk_manifest.json#L111

Edit: Yes, using ctrl-z to pause and edit the wasm-binaries-arm64.tbz2->wasm-binaries.tbz2 for both entries in emsdk_manifest.json after it gets cloned allowed the emsdk to finish building successfully. But then emconfigure for zlib was unsuccessful with an error which might indicate not finding a compiler:

[ 98%] Building CXX object unittest/CMakeFiles/unittest.dir/test_hashutil.cpp.o
[100%] Building CXX object unittest/CMakeFiles/unittest.dir/test_InodeCache.cpp.o
[100%] Linking CXX executable unittest
make[4]: Leaving directory '/src/emsdk/emsdk/ccache/git-emscripten_64bit/build_emscripten_64'
[100%] Built target unittest
make[3]: Leaving directory '/src/emsdk/emsdk/ccache/git-emscripten_64bit/build_emscripten_64'
make[2]: Leaving directory '/src/emsdk/emsdk/ccache/git-emscripten_64bit/build_emscripten_64'
Done installing tool 'ccache-git-emscripten-64bit'.
cd emsdk && ./emsdk activate --embedded --build=Release 3.1.14
embedded mode is now the only mode available
Resolving SDK version '3.1.14' to 'sdk-releases-upstream-ade9d780ff17c88d81aa13860361743e3c1e1396-64bit'
Setting the following tools as active:
   node-14.18.2-64bit
   releases-upstream-ade9d780ff17c88d81aa13860361743e3c1e1396-64bit

Next steps:
- To conveniently access emsdk tools from the command line,
  consider adding the following directories to your PATH:
    /src/emsdk/emsdk
    /src/emsdk/emsdk/node/14.18.2_64bit/bin
    /src/emsdk/emsdk/upstream/emscripten
- This can be done for the current shell by running:
    source "/src/emsdk/emsdk/emsdk_env.sh"
- Configure emsdk in your shell startup scripts by running:
    echo 'source "/src/emsdk/emsdk/emsdk_env.sh"' >> $HOME/.bash_profile
touch emsdk/.complete
make[1]: Leaving directory '/src/emsdk'
date +"[%F %T] done building emsdk."
[2022-07-01 08:24:32] done building emsdk.
date +"[%F %T] Building cpython..."
[2022-07-01 08:24:33] Building cpython...
make -C /src/cpython
make[1]: Entering directory '/src/cpython'
[ -d /src/cpython/downloads ] || mkdir /src/cpython/downloads
wget -q -O /src/cpython/downloads/Python-3.10.2.tgz https://www.python.org/ftp/python/3.10.2/Python-3.10.2.tgz
shasum --algorithm 256 --check checksums --quiet || (rm /src/cpython/downloads/Python-3.10.2.tgz; false)
[ -d /src/cpython/build/Python-3.10.2 ] || (mkdir -p /src/cpython/build/; tar -C /src/cpython/build/ -xf /src/cpython/downloads/Python-3.10.2.tgz)
cat patches/*.patch | (cd /src/cpython/build/Python-3.10.2 ; patch -p1)
patching file Objects/call.c
patching file Objects/descrobject.c
patching file Objects/methodobject.c
patching file config.sub
patching file configure
patching file configure.ac
patching file Modules/posixmodule.c
patching file Lib/platform.py
patching file Lib/test/libregrtest/main.py
patching file Lib/test/support/script_helper.py
patching file Lib/test/test_cgi.py
patching file Lib/test/test_fcntl.py
patching file Lib/test/test_gzip.py
patching file Lib/test/test_itertools.py
patching file Modules/Setup
patching file Modules/_ctypes/cfield.c
patching file Lib/test/test_code.py
patching file Python/importdl.c
patching file Objects/methodobject.c
patching file Misc/NEWS.d/next/Library/2022-03-08-11-34-06.bpo-23325.3VQnfo.rst
patching file Modules/signalmodule.c
patching file Modules/_ctypes/callbacks.c
patching file Modules/_ctypes/callproc.c
patching file Modules/signalmodule.c
patching file Python/ceval.c
touch /src/cpython/build/Python-3.10.2/.patched
[ -d /src/cpython/downloads ] || mkdir /src/cpython/downloads
wget -q -O /src/cpython/downloads/zlib-1.2.12.tar.gz https://zlib.net/zlib-1.2.12.tar.gz
[ -d /src/cpython/build ] || (mkdir /src/cpython/build)
tar -C /src/cpython/build/ -xf /src/cpython/downloads/zlib-1.2.12.tar.gz
cd /src/cpython/build/zlib-1.2.12; emconfigure ./configure
configure: ./configure
Compiler error reporting is too harsh for ./configure (perhaps remove -Werror).
** ./configure aborting.
emconfigure: error: './configure' failed (returned 1)
make[1]: *** [Makefile:95: /src/cpython/build/zlib-1.2.12/.configured] Error 1
make[1]: Leaving directory '/src/cpython'
make: *** [Makefile:220: /src/cpython/installs/python-3.10.2/lib/python3.10] Error 2

Edit: keep an eye for resolution on emscripten-core/emsdk#1040

[rth]

Installing dependencies via conda / conda-forge for linux/arm64 and Mac OS M1 CPU should work fine with no Docker related overhead. See docs. In that context, do you feel it's still useful to have a arm64 Docker image? It's would just be more maintenance effort to support this images generally.

[agriyakhetarpal]

Hi! I suppose with recent ARM systems coming out; not just how the macOS M-series lineup continues to evolve but also the newer Windows ARM laptops are building an ecosystem, it might now be useful to have a linux/arm64 Docker image, despite the maintenance effort? As an M-series user, I find myself working with GitHub Actions for this reason – emulation under QEMU is quite slow, and it takes several hours to spin up an amd64 Docker container on an arm64 machine. The circumstances from the above discussions might have changed by now.

I suspect at least a few architecture dependent fixes would be necessary

These might not be required now, because the version of the file on the stable branch does not download anything architecture-specific for NumPy (but I'm not sure about other packages, I haven't checked). Though, yes, the correct browser binaries will still have to be downloaded, prepended with a $ uname -m check to match the architecture being built (not sure if there is a better way to detect the host architecture inside a Dockerfile).

I would be happy to give this a start – please let me know if there are any suggestions before I do!

[ryanking13]

@agriyakhetarpal

What's your plan for the docker image? If you plan to build a whole Pyodide distribution with it, then I think it makes sense, and I would be happy to accept any contributions to the Dockerfile.

But, if your goal is to build specific packages out-of-tree, rather than build whole Pyodide distribution, I think it is too much effort to make a docker image for it. (+ we don't want to give the impression that you need to use a docker image to build a package out-of-tree).

[agriyakhetarpal]

Hi, @ryanking13 – while my plan for those Docker containers remains mostly for personal use, i.e., being able to build specific packages out-of-tree for debugging, but as a part of the greater goal it would be great if a whole Pyodide distribution can be built inside in it too (a complete build instead of partial). I guess adding arm64 support for it will make it build much faster and efficiently on an arm64 system rather than using emulation, and my intention is that the Docker image can be supplied to users through the existing place where it is mentioned in the documentation (so that the notion of it being a method to build from source remains, but that official support gets extended to include another architecture).

[ryanking13]

I see. Supporting ARM systems will help a lot of users (especially those with M1+ macs), so if support for both systems is possible in a way that isn't too complicated, I will be happy to accept the patch, so please feel free to experiment with our Dockerfile and run_docker script.

Personally, I think it's okay to completely rewrite both files if you need.