I'm trying to (cross)compile my automake project, which is originally developed for linux/x86_64, within a docker container running on an Apple Macbook with M1 chip.
The docker host (mac) is version 20.10.14, build a224086
The base image is debian:stable, here's the very basic Dockerfile:
FROM debian:stable
USER root
RUN apt-get update
RUN apt-get -y upgrade
RUN apt-get -y install build-essential libtool git gperf gengetopt python3-dev \
libsm-dev libjpeg-dev libtiff-dev libxerces-c-dev \
libre2-dev libpcap-dev libsqlite3-dev libsysfs-dev vim
ENTRYPOINT ["/bin/bash"]
gcc -v inside the container gives me:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/10/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)
All the binaries of the compiler toolchain are a symlink to the actual aarch64-xxx variant, such as:
/usr/bin/gcc-10 -> /usr/bin/aarch64-linux-gnu-gcc-10
/usr/bin/g++-10 -> /usr/bin/aarch64-linux-gnu-g++-10
/usr/bin/ld -> /usr/bin/aarch64-linux-gnu-ld
If I configure my project, it fails with an unknown target:
$ export TARGET=aarch64-linux-gnu
$ export BUILD=aarch64-linux-gnu
$ export HOST=aarch64-linux-gnu
$ ../../src/configure --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
<SNIP>
checking build system type... aarch64-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking target system type... aarch64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
<SNIP>
unknown target aarch64-unknown-linux-gnu
Where on earth is the unknown in aarch64-unknown-linux-gnu coming from, when everything in my toolchain says aarch64-linux-gnu?
Is it possible that this is a result of the output generated by one of libtoolize, aclocal, autoconf, autoheader or automake?
Well that's embarrassing. We have a check for the cpu type in our configure.ac and nobody came across aarch64 before, so that check entered the default case every time, which was to exit.