I am attempting to cross compile from Windows to Linux using gcc-arm-9.2-2019.12-mingw-w64-i686-arm-none-linux-gnueabihf. We are building with static runtime lib using -static-libgcc and -static-libstdc++. Everything builds and appears to run, however, the static variables that should be initialized to a value appear to all still be 0. I assume that the initialization of the crt isn't occurring, but I'm not sure how to fix that. We've been building this same setup on Linux directly with distro provided arm-linux-gnueabihf toolchains without issue in the past. This is our first attempt to build with this toolchain from Windows. Does anyone have experience with something similar?
Hi there, thanks for asking a question in the Arm Community. Just to make sure that we can get you the correct answer, I have moved your question to the Compilers and Libraries forum. Many thanks.
Perhaps it would be helpful for me to post a version of the linking command. This is cleaned up version of what is being run (names are changed and a lot of .o files are removed to simplify.
arm-none-linux-gnueabihf-g++.exe -O3 -DNDEBUG -static-libgcc -static-libstdc++ -o myapp first.cpp.o second.cpp.o -LE:/boost/stage/lib -LE:/linux/lib -Wl,-rpath,E:/dev/boost/stage/lib:E:/dev/linux/lib libLibrary.a -lboost_chrono -lboost_coroutine -lboost_context -lboost_date_time -lboost_filesystem -lboost_iostreams -lboost_program_options -lboost_regex -lboost_serialization -lboost_signals -lboost_system -lboost_thread -lboost_wserialization -lboost_log -lcrypto -lssl -ldns_sd -lavahi-client -lavahi-common -ldbus-1 -lsystemd -llzma -lselinux -llz4 -lgcrypt -lpcre -lgpg-error -lpthread -ludev -lstdc++fs -ldl -lgpiod -lm
At the point the only thought I've had is to see if directly adding crtbegin.o and friends are needed with this setup, but as I haven't had to do that in the past, I'm really not sure what might be going on.
Does the application initialize properly if it is compiled on Linux, but with the Arm provided toolchain instead of the distro-provided toolchain?
You may want to apply verbosity options (-v) to the compilation and linking commands, to see the complete command that gcc/g++ executes.
Apologies. I thought the difference was just between the toolchains, but there was a very subtle difference in the link order between how the two versions were being built that lead to an initialization order conflict.