Closed av4625 closed 1 year ago
When building gtest using this method the output from objdump is:
$ arm-linux-gnueabihf-objdump -x /home/user/.conan/data/gtest/1.12.1/_/_/package/82042c4a7e8627082d8732454220ac7ae2131c71/lib/libgtest.a | grep architecture | head -n 1
architecture: armv7, flags 0x00000011:
$ objdump -x /home/user/.conan/data/gtest/1.12.1/_/_/package/82042c4a7e8627082d8732454220ac7ae2131c71/lib/libgtest.a | grep architecture | head -n 1
architecture: UNKNOWN!, flags 0x00000011:
This is the output from boost:
$ arm-linux-gnueabihf-objdump -x /home/user/.conan/data/boost/1.81.0/_/_/package/93a617ae865233fe06a96c2acf7843b42f0fea05/lib/libboost_url.a | grep architecture | head -n 1
arm-linux-gnueabihf-objdump: src.o: file format not recognized
$ arm-linux-gnueabihf-objdump -x /home/user/.conan/data/boost/1.81.0/_/_/package/93a617ae865233fe06a96c2acf7843b42f0fea05/lib/libboost_thread.a | grep architecture | head -n 1
arm-linux-gnueabihf-objdump: thread.o: file format not recognized
arm-linux-gnueabihf-objdump: once.o: file format not recognized
arm-linux-gnueabihf-objdump: future.o: file format not recognized
$ objdump -x /home/user/.conan/data/boost/1.81.0/_/_/package/93a617ae865233fe06a96c2acf7843b42f0fea05/lib/libboost_url.a | grep architecture | head -n 1
architecture: i386:x86-64, flags 0x00000011:
$ objdump -x /home/user/.conan/data/boost/1.81.0/_/_/package/93a617ae865233fe06a96c2acf7843b42f0fea05/lib/libboost_thread.a | grep architecture | head -n 1
architecture: i386:x86-64, flags 0x00000011:
Looks like boost is not using the cross compiler but is using the system compiler. I think b2 is doing the same.
I have tried taking the conan cmake wrapper out of the equation.
I used these profiles: Host
[settings]
os=Linux
os_build=Linux
arch=armv7hf
arch_build=armv7hf
build_type=Release
compiler=gcc
compiler.version=11.3
compiler.libcxx=libstdc++11
compiler.cppstd=17
[options]
[build_requires]
[env]
CHOST=arm-linux-gnueabihf
CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER
CONAN_CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY
CONAN_CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
CONAN_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ONLY
AR=arm-linux-gnueabihf-ar
AS=arm-linux-gnueabihf-as
RANLIB=arm-linux-gnueabihf-ranlib
LD=arm-linux-gnueabihf-ld
STRIP=arm-linux-gnueabihf-strip
CC=arm-linux-gnueabihf-gcc-11
CXX=arm-linux-gnueabihf-g++-11
[buildenv]
CHOST=arm-linux-gnueabihf
CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER
CONAN_CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY
CONAN_CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
CONAN_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ONLY
AR=arm-linux-gnueabihf-ar
AS=arm-linux-gnueabihf-as
RANLIB=arm-linux-gnueabihf-ranlib
LD=arm-linux-gnueabihf-ld
STRIP=arm-linux-gnueabihf-strip
CC=arm-linux-gnueabihf-gcc-11
CXX=arm-linux-gnueabihf-g++-11
Build
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.version=11.3
compiler.libcxx=libstdc++11
compiler.cppstd=17
[options]
[build_requires]
[env]
CC=gcc
CXX=g++
[buildenv]
CC=gcc
CXX=g++
I run this command:
conan install -r conancenter boost/1.81.0@ -pr:b=default -pr:h=orangepi --update --build missing
I get this error:
boost/1.81.0: ERROR: Package '03a1da9efd1499075af320e65aa68e212d39ae33' build failed
boost/1.81.0: WARN: Build folder /home/user/.conan/data/boost/1.81.0/_/_/build/03a1da9efd1499075af320e65aa68e212d39ae33/build-release
ERROR: boost/1.81.0: Error in build() method, line 880
self.run(full_command)
ConanException: Error 1 while executing b2 -mfloat-abi=hard -q numa=on target-os=linux architecture=arm address-model=32 binary-format=elf abi=aapcs --layout=system --user-config=/home/user/.conan/data/boost/1.81.0/_/_/source/src/tools/build/user-config.jam -sNO_ZLIB=0 -sNO_BZIP2=0 -sNO_LZMA=1 -sNO_ZSTD=1 boost.locale.icu=off --disable-icu boost.locale.iconv=on boost.locale.iconv.lib=libc threading=multi visibility=hidden link=static variant=release --with-atomic --with-chrono --with-container --with-context --with-contract --with-coroutine --with-date_time --with-exception --with-fiber --with-filesystem --with-graph --with-iostreams --with-json --with-locale --with-log --with-math --with-nowide --with-program_options --with-random --with-regex --with-serialization --with-stacktrace --with-system --with-test --with-thread --with-timer --with-type_erasure --with-url --with-wave toolset=gcc cxxflags=-std=c++17 define=_GLIBCXX_USE_CXX11_ABI=1 pch=on -sLIBBACKTRACE_PATH=/home/user/.conan/data/libbacktrace/cci.20210118/_/_/package/5cc1d3891344069b65da13c045ea49880c271674 linkflags="" cxxflags="-fPIC -DBOOST_STACKTRACE_ADDR2LINE_LOCATION=/usr/bin/addr2line" install --prefix=/home/user/.conan/data/boost/1.81.0/_/_/package/03a1da9efd1499075af320e65aa68e212d39ae33 -j4 --abbreviate-paths -d0 --debug-configuration --build-dir="/home/user/.conan/data/boost/1.81.0/_/_/build/03a1da9efd1499075af320e65aa68e212d39ae33/build-release"
Tried adding buildenv
that other issues talk about but it didn't help
I ran into the same issue. @av4625 did you find a fix or workaround?
Hi @av4625 and @lukasberbuer - thanks for the detailed report.
is the issue exclusive to boosturl or does it happen with other components when cross-building?
Yes, cross-building of my other requirements (spdlog, catch2, openssl, zlib, ...) seems to work.
Edit: It's the same issue for all compiled boost libraries
Test with objdump:
$ arm-linux-gnueabihf-objdump -x ~/.conan/data/spdlog/1.11.0/_/_/package/.../lib/libspdlog.a | grep architecture | head -n 1
architecture: armv7, flags 0x00000011:
$ arm-linux-gnueabihf-objdump -x ~/.conan/data/boost/1.80.0/_/_/package/.../lib/libboost_program_options.a | grep architecture | head -n 1
arm-linux-gnueabihf-objdump: cmdline.o: file format not recognized
arm-linux-gnueabihf-objdump: config_file.o: file format not recognized
arm-linux-gnueabihf-objdump: options_description.o: file format not recognized
arm-linux-gnueabihf-objdump: parsers.o: file format not recognized
arm-linux-gnueabihf-objdump: variables_map.o: file format not recognized
arm-linux-gnueabihf-objdump: value_semantic.o: file format not recognized
arm-linux-gnueabihf-objdump: positional_options.o: file format not recognized
arm-linux-gnueabihf-objdump: utf8_codecvt_facet.o: file format not recognized
arm-linux-gnueabihf-objdump: convert.o: file format not recognized
arm-linux-gnueabihf-objdump: winmain.o: file format not recognized
arm-linux-gnueabihf-objdump: split.o: file format not recognized
I see, thanks!! I'll try to reproduce :)
Just found some hints in the logs why boost is falling back to another compiler 😕
boost/1.80.0: WARN: Patching user-config.jam
boost/1.80.0: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
boost/1.80.0: WARN:
using "gcc" : : "/usr/bin/g++" :
;
notice: Searching '/home/lb/.conan/data/boost/1.80.0/_/_/source/src/tools/build' for user-config configuration file 'user-config.jam'.
notice: Loading user-config configuration file 'user-config.jam' from '/home/lb/.conan/data/boost/1.80.0/_/_/source/src/tools/build'.
notice: will use '/usr/bin/g++' for gcc, condition <toolset>gcc-11
notice: using gcc libraries :: <toolset>gcc-11 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64
notice: using gcc archiver :: <toolset>gcc-11 :: /usr/bin/ar
warning: toolset gcc initialization: can not find tool windres
@lukasberbuer - I can see the logic where this is set - I'm surprised it doesn't honour the CXX
variable t hat you set in the [buildenv]
section.
Could you try adding the following to your host profile and then attempt the build again?
[conf]
tools.build:compiler_executables={"cpp": "arm-linux-gnueabihf-g++-11", "c": "arm-linux-gnueabihf-gcc-11"}
@jcar87 This comment also shows me showing the output for boost thread as well as url and both are the same: https://github.com/conan-io/conan-center-index/issues/16695
I too am seeing this: https://github.com/conan-io/conan-center-index/issues/16695
I will try and find some time soon to try your suggestion!
@lukasberbuer the only work around I have found currently (and its terrible) is to do a native build on the arm machine. Tar everything in the conan boost package
directory. Then do my cross compiled build and replace the package
directory with the one I tarred from the arm device. Defeats the purpose of using conan though. My arm device doesn't have a lot of ram so took hours to build and failed a few times as it ran out of ram :(
Tahnks @av4625 - same thing, if you could try adding that conf I mentioned above to your host profile, and report back, that would be great - in the meantime I'll review the logic to retrieve it from the CC/CXX variables!
thanks!
Thanks @jcar87! As suggested, I just added following to the host profile:
[conf]
tools.build:compiler_executables={"cpp": "arm-linux-gnueabihf-g++-11", "c": "arm-linux-gnueabihf-gcc-11"}
I still get the same errors as described above, but maybe the log messages are interesting:
notice: will use 'arm-linux-gnueabihf-g++-11' for gcc, condition <toolset>gcc-11
notice: using gcc libraries :: <toolset>gcc-11 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64
notice: using gcc archiver :: <toolset>gcc-11 :: arm-linux-gnueabihf-ar
warning: toolset gcc initialization: can not find tool windres
I've had a further chance to look into this.
@av4625, your original issue (with cmake-conan), stems from the details in the host profile, as per your first post:
Configuration (profile_host):
[settings]
arch=armv7
arch_build=armv7
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=11.3
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
AR=arm-linux-gnueabihf-ar
AS=arm-linux-gnueabihf-as
CC=/usr/bin/arm-linux-gnueabihf-gcc-11
CHOST=arm-linux-gnueabihf
CONAN_CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
CONAN_CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY
CONAN_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ONLY
CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER
CXX=/usr/bin/arm-linux-gnueabihf-g++-11
LD=/usr/bin/arm-linux-gnueabihf-ld
RANLIB=arm-linux-gnueabihf-ranlib
STRIP=arm-linux-gnueabihf-strip
[buildenv]
CC=gcc
CXX=g++
the [buildenv]
section is setting the CC
and CXX
variables to what's presumably your local native compiler - that's what the recipe is set to honour, and thus that's why the x86_64 compiler is used.
When invoking conan directly as per your comment here: https://github.com/conan-io/conan-center-index/issues/16695#issuecomment-1483363508 - I am able to build it just fine with the correct architecture - although I've used a compiler targetting aarch64:
[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release
[buildenv]
CHOST=aarch64-linux-gnu
AR=aarch64-linux-gnu-ar
AS=aarch64-linux-gnu-as
RANLIB=aarch64-linux-gnu-ranlib
LD=aarch64-linux-gnu-ld
STRIP=aarch64-linux-gnu-strip
CC=aarch64-linux-gnu-gcc-11
CXX=aarch64-linux-gnu-g++-11
In your case you'd have to replace aarch64-linux-gnu-
with arm-linux-gnueabihf-
, as well as changing the arch / version if it applies.
The relevant part of the build prints this for me, with a successful build afterwards:
notice: will use 'aarch64-linux-gnu-g++-11' for gcc, condition <toolset>gcc-11
notice: using gcc libraries :: <toolset>gcc-11 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64
notice: using gcc archiver :: <toolset>gcc-11 :: aarch64-linux-gnu-ar
warning: toolset gcc initialization: can not find tool windres
warning: initialized from /home/julius/.conan/data/boost/1.81.0/_/_/source/src/tools/build/user-config.jam:5
notice: using rc compiler :: <toolset>gcc-11 :: /usr/bin/as
@av4625, @lukasberbuer, may I suggest:
git clone https://github.com/conan-io/conan-center-index.git
cd conan-center-index
conan create recipes/boost/all 1.81.0@ --profile:host your_host_profile --profile:build default -o"boost:debug_level=1"
If you could attach the entire output of running the command as above, I will investigate further, cheers!
@jcar87 thanks, I will give that a go. I decided to remove cmake-conan from the equation as I wasn't sure how to add the buildenv
section
I got the same problem as I did here: https://github.com/conan-io/conan-center-index/issues/16695#issuecomment-1483363508
I had to add --build=missing
to your command.
output.txt
Edit:
Do you know how to set the [buildenv]
section using cmake-conan
in the conan_cmake_install
command?
Thanks for diving deep @jcar87! I tried your steps with the same results as @av4625:
~/.conan/profiles/default
:
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
~/.conan/profiles/armv7
:
[settings]
os=Linux
arch=armv7
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release
[buildenv]
CHOST=arm-linux-gnueabihf
AR=arm-linux-gnueabihf-ar
AS=arm-linux-gnueabihf-as
RANLIB=arm-linux-gnueabihf-ranlib
LD=arm-linux-gnueabihf-ld
STRIP=arm-linux-gnueabihf-strip
CC=arm-linux-gnueabihf-gcc-11
CXX=arm-linux-gnueabihf-g++-11
Output of conan create recipes/boost/all 1.81.0@ --profile:host armv7 --profile:build default -o"boost:debug_level=1"
:
output_conan_center_index.txt
Hi @lukasberbuer and @av4625 - thank you for running the command and attaching your build logs.
The good news is that I can see the build appears correctly configured to cross-build Boost for ARM.
The bad news is that it is failing for something specific to 32-bit ARM:
gcc.compile.asm /home/lb/.conan/data/boost/1.81.0/_/_/build/ee88e4e78fdd19f4c17bdc0968692568847a4988/build-release/boost/bin.v2/libs/context/build/gcc-11/rls/abi-apcs/lnk-sttc/nm-on/thrd-mlt/vsblt-hdn/asm/jump_arm_aapcs_elf_gas.o
jump_arm_aapcs_elf_gas.S: Assembler messages:
jump_arm_aapcs_elf_gas.S:57: Error: selected processor does not support `vstmia sp,{d8-d15}' in ARM mode
jump_arm_aapcs_elf_gas.S:68: Error: selected processor does not support `vldmia sp,{d8-d15}' in ARM mode
"arm-linux-gnueabihf-g++-11" -x assembler-with-cpp -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -I/home/lb/.conan/data/libbacktrace/cci.20210118/_/_/package/2d7ebe5aec211724d06c7670bb80889f73c8ff36/include -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DBOOST_USE_NUMA -DNDEBUG -D_GLIBCXX_USE_CXX11_ABI=1 -I"." -c -o "/home/lb/.conan/data/boost/1.81.0/_/_/build/ee88e4e78fdd19f4c17bdc0968692568847a4988/build-release/boost/bin.v2/libs/context/build/gcc-11/rls/abi-apcs/lnk-sttc/nm-on/thrd-mlt/vsblt-hdn/asm/jump_arm_aapcs_elf_gas.o" "libs/context/src/asm/jump_arm_aapcs_elf_gas.S"
...failed gcc.compile.asm /home/lb/.conan/data/boost/1.81.0/_/_/build/ee88e4e78fdd19f4c17bdc0968692568847a4988/build-release/boost/bin.v2/libs/context/build/gcc-11/rls/abi-apcs/lnk-sttc/nm-on/thrd-mlt/vsblt-hdn/asm/jump_arm_aapcs_elf_gas.o...
gcc.compile.asm /home/lb/.conan/data/boost/1.81.0/_/_/build/ee88e4e78fdd19f4c17bdc0968692568847a4988/build-release/boost/bin.v2/libs/context/build/gcc-11/rls/abi-apcs/lnk-sttc/nm-on/thrd-mlt/vsblt-hdn/asm/ontop_arm_aapcs_elf_gas.o
ontop_arm_aapcs_elf_gas.S: Assembler messages:
ontop_arm_aapcs_elf_gas.S:57: Error: selected processor does not support `vstmia sp,{d8-d15}' in ARM mode
ontop_arm_aapcs_elf_gas.S:71: Error: selected processor does not support `vldmia sp,{d8-d15}' in ARM mode
"arm-linux-gnueabihf-g++-11" -x assembler-with-cpp -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -I/home/lb/.conan/data/libbacktrace/cci.20210118/_/_/package/2d7ebe5aec211724d06c7670bb80889f73c8ff36/include -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DBOOST_USE_NUMA -DNDEBUG -D_GLIBCXX_USE_CXX11_ABI=1 -I"." -c -o "/home/lb/.conan/data/boost/1.81.0/_/_/build/ee88e4e78fdd19f4c17bdc0968692568847a4988/build-release/boost/bin.v2/libs/context/build/gcc-11/rls/abi-apcs/lnk-sttc/nm-on/thrd-mlt/vsblt-hdn/asm/ontop_arm_aapcs_elf_gas.o" "libs/context/src/asm/ontop_arm_aapcs_elf_gas.S"
...failed gcc.compile.asm /home/lb/.conan/data/boost/1.81.0/_/_/build/ee88e4e78fdd19f4c17bdc0968692568847a4988/build-release/boost/bin.v2/libs/context/build/gcc-11/rls/abi-apcs/lnk-sttc/nm-on/thrd-mlt/vsblt-hdn/asm/ontop_arm_aapcs_elf_gas.o...
This would explain why my different cross-building attempts were successful, as I was not trying 32-bit ARM.
Looking at https://github.com/boostorg/context/issues/114 where this issue has been previously reported - it looks like the following flags would have to be added -mcpu=cortex-a5 -mfpu=neon-vfpv4 -mfloat-abi=hard
so that the assembler has knowledge of the specific cpu/architecture features.
However, those flags need to match the specific CPU you are targeting. If you are able to provide details of the specific ARM SoC you are targetting, I can look this up or point you in the right direction.
@av4625, you mentioned that building natively on your ARM devices was successful. Chances are, the compiler you are using on the device is already pre-built to match the CPU you are using, and already passes the correct flags. Would you be able to run the following command locally on your ARM device to check which flags are being passed?
cat "void foo();" | gcc -x c -v -
Thanks!
Then we can take it from there :D
Big steps forward, thanks @jcar87!
In the morning, I tried to build the armv7 Conan packages via Docker and realized the same, that armv7 + boost is the problem and not the cross-build.
Small example to reproduce with an arm32v7/ubuntu:22.04
Docker image. Dockerfile
:
FROM arm32v7/ubuntu:22.04
RUN apt update
RUN apt install -y build-essential cmake
RUN apt install -y python3 python3-pip
RUN pip3 install conan~=1.59
RUN conan profile new default --detect
RUN conan profile update settings.compiler.libcxx=libstdc++11 default
RUN cat ~/.conan/profiles/default
RUN conan install boost/1.81.0@ -s build_type=Debug --update --build missing
Now build the Docker image:
docker build --progress=plain .
Thanks for spending the time on this! output.txt
I included the command you specified and also 2 more as yours errored, I created a file and compiled for c and c++. The file included:
int main(){}
From what I can see I don't think it sets -mcpu
and -mfpu
. But it sets -march=armv7-a+fp
which maybe covers the -mfpu
.
I should probably use these options when compiling my own program and conan deps:
-mfloat-abi=hard -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+fp -march=armv7-a+fp
The CPU of the device is a Cortex-A7
. So I could add -mcpu
and -mtune
.
I'm not sure what to choose for -mfpu
. Maybe the answer is below for someone who knows more than me!
% cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 48.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 48.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 48.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 48.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
Hardware : Allwinner sun8i Family
Revision : 0000
% uname -a
Linux orangepizero 5.15.93-sunxi #23.02.2 SMP Fri Feb 17 23:49:46 UTC 2023 armv7l armv7l armv7l GNU/Linux
Hi @av4625, you're on the right track: indeed -march=armv7-a+fp
encompasses the equivalent of setting some of the other flags (-mpfu for example). It would appear as much from the GCC documentation: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
Based on the information you have provided, I believe the following flags would work for your target CPU:
-mcpu=cortex-a7 -mfpu=neon-vfpv3 -mfloat-abi=hard
mfpu
is -vfpv3
on the one hand (as that is the value according to the documentation when -march=armv7-a+fp
), and I've taken the liberty to add neon
as I can see this featured in your /proc/cpuinfo
-mfloat-abi=hard
since that's what gnueabihf
implies, this one may be redundantI can see that the Boost recipe will pick up ASFLAGS
from the environment to pass to the assembler - so you can define it in [buildenv]
along with the others.
All in all, the host profile would look like:
[settings]
os=Linux
arch=armv7
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release
[buildenv]
CHOST=arm-linux-gnueabihf
AR=arm-linux-gnueabihf-ar
AS=arm-linux-gnueabihf-as
RANLIB=arm-linux-gnueabihf-ranlib
LD=arm-linux-gnueabihf-ld
STRIP=arm-linux-gnueabihf-strip
CC=arm-linux-gnueabihf-gcc-11
CXX=arm-linux-gnueabihf-g++-11
ASFLAGS=-mcpu=cortex-a7 -mfpu=neon-vfpv3 -mfloat-abi=hard
with these changes now I'm able to cross-build boost for armv7 - hopefully this helps!
As mentioned previously, this appears to be an instance of the issue reported here: https://github.com/boostorg/context/issues/114
but also in combination with how the gcc cross-compiler provided by Ubuntu is built: https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1939379 (looks like the info from -march
is not passed to the assembler).
Thanks for this! I’ll give it a go.
I just need to figure out how to populate [buildenv]
with cmake conan.
Is there a good way to know what env variables you should use? I naively thought I would use CFLAGS
/CPPFLAGS
as I didn’t know ASFLAGS
where a thing.
Will ASFLAGS work with all 3rd party deps I get with conan or is this something I’ll need to check?
I find the conan documentation lacking (or at least I can’t find it) when it comes to all available settings/variables for profiles, I can just find examples and hopefully they contain what I need!
I'm starting to see that you can find out the available settings/variables from the recipes. I have only used conan for simple use cases before, this is the first time I'm doing more awkward things with it and learning along the way.
@jcar87 Thank you very much for your help. I have finally got it to work.
I settled on the following compiler options:
-mfloat-abi=hard -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+fp -mtune=cortex-a7 -mfpu=neon-vfpv3
I had to remove -mcpu
as I. was getting:
switch '-mcpu=cortex-a7` conflicts with switch '-march=armv7-a+fp'
One slightly interesting thing is that doing cat "void foo();" | arm-linux-gnueabihf-gcc-11 -x c -v -
on the linux machine shows the same output and uses the same options as doing it on the arm device itself. But I have decided to explicitly provide all the options myself now.
I will close this issue here as I believe everything is answered/fixed relating to this. I opened a question about how to add [buildenv]
with cmake-conan
. I will link it here incase anyone comes across this.
To get it working currently I created a profile file in my repo and added the following to my cmake (I'd rather not do it this way as most of the settings/vars in the profile duplicate the things in my cmake toolchain file):
set(CONAN_INSTALL_DATA
SETTINGS_BUILD ${build_settings}
PROFILE_HOST ${CMAKE_SOURCE_DIR}/toolchains/orange_pi/conan_profile)
conan_cmake_install(
PATH_OR_REFERENCE .
BUILD missing
REMOTE conancenter
${CONAN_INSTALL_DATA})
Proof :)
$ arm-linux-gnueabihf-objdump -x /home/user/.conan/data/boost/1.81.0/_/_/package/5da9c4c21f3aeffce6fb5f7defa8feccf7677405/lib/libboost_url.a | grep architecture | head -n 1
architecture: armv7, flags 0x00000011:
Environment details
Steps to reproduce
This is how I include boost in my project. It works fine if I am compiling for the native system (not OrangePi). But when I try to cross compile (for OrangePi) I get the error below when it tries to link
boosturl
.As
b2
is needed, I'm not sure if it is correctly using the cross compiler when building it from the output.Logs
You will see I also have gtest and nlohmann_json, I removed these from this post as they build correctly.
cmake command
build command