Hi all,

there was some back and forth recently with arm64. It was moved to crosstool-ng, which broke some backwards compatibility and the fortran compiler was lost. Some of this has been fixed already. However, there was a state of confusion in which some path changes were made that had no real effect.

Today I took some time and compared the arm64 container to the other two crosstool-ng containers, mips and s390x, and could see that the configuration of arm64 differs significantly from the other two, which are well aligned.

What I'd like to do in this pull request is revisit the arm64 move to crosstool-ng, and align it well to the other two targets, and only afterwards fix the open issue that the crosscompiler binaries are not in $PATH. In the current state of the PR, arm64, mips and s390x only differ in the target triples, which is the desired state imo.

@nadav-eyesight, would you be so kind and review this pull request. In your original PR, you additionally introduced some arm64 dev libraries, manually installed qemu from source and added new debian repos. I think the first one was needed because of some opengl bindings. For the other two, I unfortunately couldn't find an explanation. Could you kindly review this PR and check which of these are still needed for your use case, so I can pull respective changes in.

@marcoabreu, your fortran support should be onboard by default. If you've got some free time, kindly review it.

@thewtex, after feedback from @nadav-eyesight and @marcoabreu was received, I would go on and add a patch or new PR that finally adds the binaries of all the crosstool-ng containers to $PATH.

BR, Andre

Hi,

I have tried compile my project into armv7 to run in my raspberry pi 3 that is armv7.

My project: https://github.com/paulo-coutinho/cef-sample

Im using this commands:

git clone https://github.com/paulo-coutinho/cef-sample.git
cd cef-sample
docker run --rm dockcross/linux-armv7 > ./dockcross
chmod +x dockcross
./dockcross cmake -Bbuild -H. -GNinja -DCMAKE_BUILD_TYPE=Release -DCEF_PLATFORM=linuxarm
./dockcross cmake --build build --target MyApp --config Release -v

But im getting this error:

FAILED: libcef_dll_wrapper/CMakeFiles/libcef_dll_wrapper.dir/base/cef_atomicops_x86_gcc.cc.o 
/usr/xcc/armv7-unknown-linux-gnueabi/bin/armv7-unknown-linux-gnueabi-g++ --sysroot=/usr/xcc/armv7-unknown-linux-gnueabi/armv7-unknown-linux-gnueabi/sysroot  -DCEF_USE_SANDBOX -DNDEBUG -DWRAPPING_CEF_SHARED -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -I../temp/cef/cef_binary_91.1.20+g5800665+chromium-91.0.4472.101_linuxarm -I /usr/xcc/armv7-unknown-linux-gnueabi/include/ -O3 -DNDEBUG   -fno-strict-aliasing -fPIC -fstack-protector -funwind-tables -fvisibility=hidden --param=ssp-buffer-size=4 -pipe -pthread -Wall -Werror -Wno-missing-field-initializers -Wno-unused-parameter -Wno-error=comment -Wno-comment -Wno-deprecated-declarations -msse2 -mfpmath=sse -mmmx -m32 -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -std=gnu++11 -Wsign-compare -Wno-undefined-var-template -Wno-literal-suffix -Wno-narrowing -Wno-attributes -O2 -fdata-sections -ffunction-sections -fno-ident -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -MD -MT libcef_dll_wrapper/CMakeFiles/libcef_dll_wrapper.dir/base/cef_atomicops_x86_gcc.cc.o -MF libcef_dll_wrapper/CMakeFiles/libcef_dll_wrapper.dir/base/cef_atomicops_x86_gcc.cc.o.d -o libcef_dll_wrapper/CMakeFiles/libcef_dll_wrapper.dir/base/cef_atomicops_x86_gcc.cc.o -c ../temp/cef/cef_binary_91.1.20+g5800665+chromium-91.0.4472.101_linuxarm/libcef_dll/base/cef_atomicops_x86_gcc.cc
armv7-unknown-linux-gnueabi-g++: error: unrecognized command line option '-msse2'
armv7-unknown-linux-gnueabi-g++: error: unrecognized command line option '-mfpmath=sse'
armv7-unknown-linux-gnueabi-g++: error: unrecognized command line option '-mmmx'
armv7-unknown-linux-gnueabi-g++: error: unrecognized command line option '-m32'
ninja: build stopped: subcommand failed.

Can you help?

You project will help a lot port the samples to arm[32,64].

Thanks.

Resolves #367.

Add support for manylinux2014-aarch64:

• Added Dockerfile, Toolchain, and crosstool config (Referred linux-arm64 wherever requried).
• Using FROM dockcross/manylinux2014-x64 image.
• Updated Makefile.
• To build manylinux2014-aarch64 locally just use 'make manylinux2014-aarch64'.
• Run test is successful. Used 'make manylinux2014-aarch64.test.
• Also added manylinux2014-aarch64 in circleCI config file referring manylinux2014-x64.

Howdy. I've spent the past three weeks compiling my project, which uses OpenCV, to Linux-arm64.

It hasn't been easy. My current solution uses hacks- manually soft linking header files from /usr/include to my cross compiler's sysroot's /include path (in my case, /opt/x-tools/aarch64-unknown-linux-gnueabi/include/.

I don't know why that is required, either I'm missing something or something's wrong with pkg-config.

This branch is my attempt to add my solution to dockcross, I doubt it's perfect in its current shape, but I'm starting the pull request so you can review it right now.

I got stuck in compiling my programm for Pi2 using ARMv6 because it links against a dependency the requires a newer glibc: /usr/lib/libSDL2.so: undefined reference to __fdelt_chk@GLIBC_2.15' /usr/lib/libSDL2.so: undefined reference togetauxval@GLIBC_2.16' The toolchain provides only glibc 2.13 .

Help would be very much appreciated. Thx Steve

Remarks: #124

(1) Linking c++ executable triggers this error:

Solved

(2) Add support for "Architecture options usage"

Rely on User

(3) Provide mechanism to switch spec (rdimon.specs , nano.specs, ...)

No Idea, but i have aarch64 in /opt/linaro directory, only need to change `cross_path` and `cross_triple` for the outpur script. Maybe you can help me out.

(4) Look into seg fault when trying to use qemu-arm:

 "--emulator "/usr/bin/qemu-arm" in Makefile

I am trying to run armv6 cross compiler on docker for windows.

bahri@BGASUS MINGW64 /c/workspace/test-pi-cross $ docker run --rm dockcross/linux-armv6 > ./dockcross

bahri@BGASUS MINGW64 /c/workspace/test-pi-cross $ ./dockcross bash [root:/work] # ls CMakeLists.txt HelloWorld.cpp build-lin-x64 dockcross helloworld.c [root:/work] # echo "int main(){return 0;}" > test.c [root:/work] # cat test.c int main(){return 0;} [root:/work] # $CC test.c cc1: fatal error: test.c: Value too large for defined data type compilation terminated. [root:/work] 1 # cp test.c /tmp/ [root:/work] # $CC /tmp/test.c [root:/work] # exit exit

I think this bug is related to https://github.com/docker/for-win/issues/15, ie, the cross compiler executable itself is not build with large file offset support. Same problem does not occur with linux-x64 cross compiler image.

Since it may not be common knowledge, we should add an explicit, small, self-contained example of building against a dependency.

Two strategies can be demonstrated -- if it is a CMake project, we can show how to build against the dependency build tree by passing <depname>_DIR. We can also show how to install into a common local install prefix directory, then use it with CMake.

We should use a relatively small, simple dependency for the example.

Suggested-by: @fbudin69500

implements the use of this solution using (recent) docker-desktop (implemented in wsl2), on windows host, from within cygwin environment. (docker command line requires windows path, the conversion between cygwin path and windows path can be obtained via the cygwin specific cygpath instruction).

Added SSH support to enable Git checkouts that use SSH instead of HTTP(S).

The SSH directory is assumed to be in $HOME/.ssh; however:

export SSH_DIR=/my/custom/dir

will override the setting and allow for configurable settings.

$SSH_DIR is then mounted as host-volume in the Docker container and placed in /home/<user>/.ssh

I am interested in building manylinux2014-aarch binaries with dockcross. There exists a pypa/manylinux2014-aarch64 image, but that docker image needs to be run on an aarch64 machine (which is exactly what we don't want in dockcross).

So I've been looking at the dockcross/linux-arm64 image. Let's first take a step back. The manylinux2014 PEP says:

The wheel's binary executables or shared objects may not link against externally-provided libraries except those in the following list:

libgcc_s.so.1*
libstdc++.so.6*
libm.so.6*
libdl.so.2*
librt.so.1*
libc.so.6*
libnsl.so.1*
libutil.so.1
libpthread.so.0*
libresolv.so.2
libX11.so.6
libXext.so.6
libXrender.so.1
libICE.so.6
libSM.so.6
libGL.so.1
libgobject-2.0.so.0
libgthread-2.0.so.0
libglib-2.0.so.0

I tried to build a binary with dockcross/linux-arm64, and in my case it is linked against (according to readelf --dynamic):

libpthread.so.0
libnsl.so.1
libdl.so.2
librt.so.1
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6

Which are all part of the PEP599 definition above (I marked them with a star (*) up there).

However, PEP599 says:

If the wheel contains binary executables or shared objects linked against any allowed libraries that also export versioned symbols, they may only depend on the following maximum versions:

GLIBC_2.17
CXXABI_1.3.7, CXXABI_TM_1 is also allowed
GLIBCXX_3.4.19
GCC_4.8.0

And in my case, objdump -T shows me one symbol using GLIBCXX_3.4.19, and one using CXXABI_1.3.8.

So in this specific case, I am not far from being manylinux2010-aarch64-compliant, except for those few symbols. I believe that it is a coincidence, and dockcross/linux-arm64 cannot give me any guarantee.

Then I naively thought that I could just take the Dockerfile of pypa/manylinux2014-aarch64 and adapt it for dockcross, but that's not working: manylinux2014 works by using a CentOS 7 base image. But when cross-compiling, what imports is the toolchain, not the base image. Right?

So how should I proceed if I wanted to create a dockcross/manylinux2014-aarch64 image, i.e. an image that would cross-compile instead of the pypa/manylinux2014-aarch64 that must run on an aarch64 machine? Any idea?

Hello Team dockcross,

I just noticed that the manylinux2014-aarch64 cannot compile simple cpp programms like:

#include <iostream>
#include <string>
int main() {
std::string str = "bla";
return 0;
}

The error message states that there is an undefined reference for std::__cxx11::basic_string:

/tmp/ccqdtlIA.o: In function `main':
someProgram.cpp:(.text+0x2c): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)'
someProgram.cpp:(.text+0x40): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
collect2: error: ld returned 1 exit status

When checking the symbols of libstdc++.so you can see that those symbols are missing. If I compile the same code using -static-libstdc++ it works, which tells me that only the dynamic libstdc++ is broken:

aarch64-unknown-linux-gnueabi-g++ someProgram.cpp -static-libstdc++

I suspect that the script manylinux2014-aarch64/xc_script/docker_setup_scrpits/copy_llibstd.sh is messing up something.

Thanks very much for your help.

Ditto. With that specification in place, a locally built image on architectures != amd64 would fail to execute the dockcross.sh script and try to pull a non-existing amd64 image from docker.io repository under the custom organisation name. That specification shall be anyway superfluous, unless one really wants to run an emulated image even if the native image is available.

Hey According to your documentation, the image:

dockcross/linux-arm64-lts Cross compiler for the 64-bit ARM platform on Linux, also known as AArch64, with Long-term support (For Ubuntu 18.04 or Debian Buster). With GCC 8.5.0 and GLibc 2.27.

But, pulling both latest/ oldest tags of it, contains GLibc 2.31. Is there any image contains the GLibc 2.27 version? Thanks a lot.

/usr/bin/x86_64-linux-gnu-ld: unrecognised emulation mode: 32
Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om elf_k1om i386pep i386pe

This leads to autoconf being confused and not wanting to use the linker:

checking if the linker (i686-linux-gnu-ld) is GNU ld... no

This appears to be caused by the .sh wrapper wrongly adding "-m32"

Workaround: set LD=ld on your autoconf line

Feels like it just got forgotten in the CI when added back here. Trying to enable it again.

Would resolve https://github.com/dockcross/dockcross/issues/722.