Conan: [bug] Cross build from Linux x86_64 to Linux armv8 fails

Created on 19 Nov 2020 · 23Comments · Source: conan-io/conan

Since I updated conan to version 1.31.3, I am not able to cross compile from amd64 to arm64 any more. I tracked it down to #7827 (https://github.com/conan-io/conan/pull/7827/files/5939976a86ac42055d79fe1abbe951b7c90daa13). When I revert the changes made in cmake_flags.py the build is working again. I'm still not sure about the underlying problem, but it seems to be related to the sysroot path.

Environment Details

Operating System+version: Debian GNU/Linux bullseye/sid
Compiler+version: aarch64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
Conan version: 1.30.1 (or above)
Python version: 3.8

Profile

````
toolchain=aarch64-linux-gnu

[env]
CONAN_CMAKE_FIND_ROOT_PATH=/usr/$toolchain
CHOST=$toolchain
AR=$toolchain-ar
AS=$toolchain-as
RANLIB=$toolchain-ranlib
CC=$toolchain-gcc
CXX=$toolchain-g++
STRIP=$toolchain-strip
RC=$toolchain-windres
PKG_CONFIG_PATH=/usr/lib/$toolchain/pkgconfig

[settings]
os=Linux
os_build=Linux
arch=armv8
arch_build=x86_64
compiler=gcc
compiler.version=10
compiler.libcxx=libstdc++11
build_type=Release
````

Logs (Executed commands with output)

````
conan build ..
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc
-- Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc - broken
CMake Error at /usr/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler

"/usr/bin/aarch64-linux-gnu-gcc"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: /home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_0ca60/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_0ca60.dir/build.make CMakeFiles/cmTC_0ca60.dir/build
gmake[1]: Entering directory '/home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_0ca60.dir/testCCompiler.c.o
/usr/bin/aarch64-linux-gnu-gcc --sysroot=/usr/aarch64-linux-gnu    -o CMakeFiles/cmTC_0ca60.dir/testCCompiler.c.o -c /home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_0ca60
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_0ca60.dir/link.txt --verbose=1
/usr/bin/aarch64-linux-gnu-gcc --sysroot=/usr/aarch64-linux-gnu CMakeFiles/cmTC_0ca60.dir/testCCompiler.c.o -o cmTC_0ca60 
/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/bin/ld: cannot find /usr/aarch64-linux-gnu/lib/libc.so.6 inside /usr/aarch64-linux-gnu
/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/bin/ld: cannot find /usr/aarch64-linux-gnu/lib/libc_nonshared.a inside /usr/aarch64-linux-gnu
/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/bin/ld: cannot find /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 inside /usr/aarch64-linux-gnu
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_0ca60.dir/build.make:106: cmTC_0ca60] Error 1
gmake[1]: Leaving directory '/home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_0ca60/fast] Error 2

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
````

Feedback please! help wanted triaging

Source

martin-koch

All 23 comments

Sorry, can you clarify the version? You said Conan 1.32 which is not released, but then reported 1.30.1?

Also if you could enable the command log (log.run_to_output in conan.conf: https://docs.conan.io/en/latest/reference/config_files/conan.conf.html?highlight=run_to_output), to display your full command, that would help (in both failing and previous version). It might be the CMAKE_SYSTEM_NAME thing

memsharded on 19 Nov 2020

Sorry, I meant version 1.31.3. I tried with 1.31.3 and 1.30.1.
Here is the output with 1.30.0
````
conan --version
Conan version 1.30.0

conan build ..
Using lockfile: '/home/martin/git/m100-common-lib/build/conan.lock'
Using cached profile from lockfile
conanfile.py (m100-common-lib/0.5.0): Calling build()
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/aarch64-linux-gnu-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: Adjusting output directories
-- Conan: Using cmake targets configuration
-- Library gmock_main found /home/jenkins/.conan/data/gtest/1.10.0/bachmann/stable/package/c5a1a0bceb8d00cc8399d0c2c30d1322e9a0769e/lib/libgmock_main.a
-- Library gmock found /home/jenkins/.conan/data/gtest/1.10.0/bachmann/stable/package/c5a1a0bceb8d00cc8399d0c2c30d1322e9a0769e/lib/libgmock.a
-- Library gtest found /home/jenkins/.conan/data/gtest/1.10.0/bachmann/stable/package/c5a1a0bceb8d00cc8399d0c2c30d1322e9a0769e/lib/libgtest.a
-- Library pthread not found in package, might be system one
-- Library m100-core-cpp found /home/jenkins/.conan/data/m100-core-cpp/0.3.0/bachmann/testing/package/c277231c6ba168e427431b3c3631fc3913008ca0/lib/libm100-core-cpp.a
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Compiler GCC>=5, checking major version 10
-- Conan: Checking correct version: 10
-- Conan: C++ stdlib: libstdc++11
-- Project version file: .version
-- Project version: 0.5.0
-- Project version [major]: 0
-- Project version [minor]: 5
-- Project version [patch]: 0
-- Project version [extra]:
-- Performing Test WITH_STACK_PROTECTOR
-- Performing Test WITH_STACK_PROTECTOR - Success
-- Performing Test WITH_STACK_PROTECTOR_STRONG
-- Performing Test WITH_STACK_PROTECTOR_STRONG - Success
-- Use -fstack-protector-strong.
-- Performing Test WITH_FORTIFY_SOURCE
-- Performing Test WITH_FORTIFY_SOURCE - Success
-- Use fortify source 2.
-- Compiler target arch : aarch64
-- Compiler C_FLAGS : -Wall -Wformat -Wformat-security -Werror=format-security -Wignored-qualifiers -fPIC -Werror -fstack-protector-strong -D_FORTIFY_SOURCE=2
-- Compiler CXX_FLAGS : -Wall -Wformat -Wformat-security -Werror=format-security -Wignored-qualifiers -fPIC -Werror -fstack-protector-strong -D_FORTIFY_SOURCE=2
-- Compiler LINKER_FLAGS : -fPIC -Wl,-z,relro -Wl,-z,now -fstack-protector-strong
-- Conan: Using autogenerated FindM100CoreCpp.cmake
-- Found M100CoreCpp: 0.3.0 (found version "0.3.0")
-- Library m100-core-cpp found /home/jenkins/.conan/data/m100-core-cpp/0.3.0/bachmann/testing/package/c277231c6ba168e427431b3c3631fc3913008ca0/lib/libm100-core-cpp.a
-- Found: /home/jenkins/.conan/data/m100-core-cpp/0.3.0/bachmann/testing/package/c277231c6ba168e427431b3c3631fc3913008ca0/lib/libm100-core-cpp.a
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found GTest: /home/jenkins/.conan/data/gtest/1.10.0/bachmann/stable/package/c5a1a0bceb8d00cc8399d0c2c30d1322e9a0769e/lib/libgtest.a
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.20") found components: doxygen missing components: dot
-- Detecting GIT version
-- Found Git: /usr/bin/git (found version "2.29.2")
-- GIT tag :
-- GIT branch : master
-- GIT commit hash : 8ae2cb2
-- GIT commit timestamp : 1605699507
-- GIT dirty : true
-- Package name : m100-common
-- Package vendor : Bachmann electronic GmbH
-- Package contact : Bachmann electronic GmbH info@bachmann.info
-- Package version : 0.5.0~20201119.153658+g8ae2cb2
-- Package version tag : unstable
-- Package section : devel
-- Package priority :
-- Package maintainer :
-- Package distribution :
-- Package architecture : arm64
-- Package filename : m100-common_0.5.0~20201119.153658+g8ae2cb2_deb11_arm64.deb
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY

-- Build files have been written to: /home/martin/git/m100-common-lib/build
Scanning dependencies of target M100Common
[ 1%] Building CXX object src/CMakeFiles/M100Common.dir/buffer.cpp.o
[ 2%] Building CXX object src/CMakeFiles/M100Common.dir/blob.cpp.o
[ 3%] Building CXX object src/CMakeFiles/M100Common.dir/datetime.cpp.o
[ 4%] Building CXX object src/CMakeFiles/M100Common.dir/command.cpp.o
[ 5%] Building CXX object src/CMakeFiles/M100Common.dir/cyclictask.cpp.o
[ 6%] Building CXX object src/CMakeFiles/M100Common.dir/datavalue.cpp.
...
And the output with version 1.30.1:
conan --version
Conan version 1.30.1

"/usr/bin/aarch64-linux-gnu-gcc"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: /home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_b3746/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_b3746.dir/build.make CMakeFiles/cmTC_b3746.dir/build
gmake[1]: Entering directory '/home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_b3746.dir/testCCompiler.c.o
/usr/bin/aarch64-linux-gnu-gcc --sysroot=/usr/aarch64-linux-gnu    -o CMakeFiles/cmTC_b3746.dir/testCCompiler.c.o -c /home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_b3746
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_b3746.dir/link.txt --verbose=1
/usr/bin/aarch64-linux-gnu-gcc --sysroot=/usr/aarch64-linux-gnu CMakeFiles/cmTC_b3746.dir/testCCompiler.c.o -o cmTC_b3746 
/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/bin/ld: cannot find /usr/aarch64-linux-gnu/lib/libc.so.6 inside /usr/aarch64-linux-gnu
/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/bin/ld: cannot find /usr/aarch64-linux-gnu/lib/libc_nonshared.a inside /usr/aarch64-linux-gnu
/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/bin/ld: cannot find /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 inside /usr/aarch64-linux-gnu
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_b3746.dir/build.make:106: cmTC_b3746] Error 1
gmake[1]: Leaving directory '/home/martin/git/m100-common-lib/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_b3746/fast] Error 2

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)

-- Configuring incomplete, errors occurred!
See also "/home/martin/git/m100-common-lib/build/CMakeFiles/CMakeOutput.log".
See also "/home/martin/git/m100-common-lib/build/CMakeFiles/CMakeError.log".
ERROR: conanfile.py (m100-common-lib/0.5.0): Error in build() method, line 39
cmake.configure()
ConanException: Error 1 while executing cd '/home/martin/git/m100-common-lib/build' && cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release" -DCMAKE_SYSTEM_NAME="Linux" -DCONAN_CMAKE_FIND_ROOT_PATH="/usr/aarch64-linux-gnu" -DCMAKE_SYSROOT="/usr/aarch64-linux-gnu" -DCONAN_IN_LOCAL_CACHE="OFF" -DCONAN_COMPILER="gcc" -DCONAN_COMPILER_VERSION="10" -DCONAN_LIBCXX="libstdc++11" -DBUILD_SHARED_LIBS="ON" -DCMAKE_INSTALL_PREFIX="/home/martin/git/m100-common-lib/build/package" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_MODULE_PATH="/home/martin/git/m100-common-lib/build" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DBUILD_WITH_COVERAGE="False" -DRUN_MEMCHECK="ON" -Wno-dev '/home/martin/git/m100-common-lib'
````

martin-koch on 19 Nov 2020

I also activated debug logs (level = debug in conan.conf). Maybe this will help too:
conan 1.30.1:
conan build .. DEBUG :conan_api.py [178]: INIT: Using config '/home/jenkins/.conan/conan.conf' [2020-11-19 16:02:33,978] DEBUG :tracer.py [156]: CONAN_API: build(conanfile_path=..,source_folder=None,package_folder=None,build_folder=None,install_folder=None,should_configure=True,should_build=True,should_install=True,should_test=True) [2020-11-19 16:02:33,980] DEBUG :build.py [17]: BUILD: folder '/home/martin/git/m100-common-lib/build' [2020-11-19 16:02:33,981] DEBUG :build.py [18]: BUILD: Conanfile at '/home/martin/git/m100-common-lib/conanfile.py' [2020-11-19 16:02:33,981] Using lockfile: '/home/martin/git/m100-common-lib/build/conan.lock' Using cached profile from lockfile DEBUG :build.py [11]: Call conanfile.build() with files in build folder: ['conan.lock', 'Findbachmann-cmake-modules.cmake', 'FindM100CoreCpp.cmake', 'conanbuildinfo.cmake', 'conanbuildinfo.txt', 'FindGTest.cmake', 'graph_info.json', 'conaninfo.txt', 'Findm100-ironerr.cmake'] [2020-11-19 16:02:34,031] conanfile.py (m100-common-lib/0.5.0): Calling build() INFO :cmake_flags.py [267]: Setting Cross build flags: CMAKE_SYSTEM_NAME=Linux, CONAN_CMAKE_FIND_ROOT_PATH=/usr/aarch64-linux-gnu, CMAKE_SYSROOT=/usr/aarch64-linux-gnu [2020-11-19 16:02:34,034]

conan 1.30:
conan build .. DEBUG :conan_api.py [178]: INIT: Using config '/home/jenkins/.conan/conan.conf' [2020-11-19 16:01:26,668] DEBUG :tracer.py [156]: CONAN_API: build(conanfile_path=..,source_folder=None,package_folder=None,build_folder=None,install_folder=None,should_configure=True,should_build=True,should_install=True,should_test=True) [2020-11-19 16:01:26,670] DEBUG :build.py [17]: BUILD: folder '/home/martin/git/m100-common-lib/build' [2020-11-19 16:01:26,671] DEBUG :build.py [18]: BUILD: Conanfile at '/home/martin/git/m100-common-lib/conanfile.py' [2020-11-19 16:01:26,671] Using lockfile: '/home/martin/git/m100-common-lib/build/conan.lock' Using cached profile from lockfile DEBUG :build.py [11]: Call conanfile.build() with files in build folder: ['conan.lock', 'Findbachmann-cmake-modules.cmake', 'FindM100CoreCpp.cmake', 'conanbuildinfo.cmake', 'conanbuildinfo.txt', 'FindGTest.cmake', 'graph_info.json', 'conaninfo.txt', 'Findm100-ironerr.cmake'] [2020-11-19 16:01:26,728] conanfile.py (m100-common-lib/0.5.0): Calling build() INFO :cmake_flags.py [266]: Setting Cross build flags: [2020-11-19 16:01:26,729]

martin-koch on 19 Nov 2020

I am not sure this is an effect of the sysroot, but probably it is an effect that #7827 does the right thing setting the CMAKE_SYSTEM_NAME, because this is clearly an scenario of cross-building, but it fails because it is missing some other important CMake variables like CMAKE_SYSTEM_PROCESSOR and friends. There is a PR https://github.com/conan-io/conan/pull/8026/files for this.

It seems complicated to revert #7827, as it seems it was a step forward on removing a declared bug: If it is cross building, it should set the CMAKE_SYSTEM_NAME. Not setting it is clearly a bug. So I'd suggest to try to move forward with setting the other vars.

Maybe you could try adding them to your CMake code, to see if it is fixed, I guess something like:

def build(self):
     cmake = CMake(self)
     cmake.definitions["CMAKE_SYSTEM_PROCESSOR"] = "aarch64"
     cmake.definitions["CMAKE_HOST_SYSTEM_NAME"] = "Linux"
     cmake.definitions["CMAKE_HOST_SYSTEM_PROCESSOR"] = "x86_64"
     cmake.configure(....

NOTE: BTW, the CMake notation is opposite to the GNU one (the one Conan is using), CMake Host=GNU Build

If you can try and it works, maybe we want to expedite #8026 into a patch release.

memsharded on 19 Nov 2020

Unfortunately setting the suggested cmake variables in the conanfile doesn't fix it.
I also tried a few other things. One thing was to unset CMAKE_SYSROOT in the conanfile like this:
cmake cmake.definitions["CMAKE_SYSROOT"] = ""
Afterwards I was able to compile the project.

martin-koch on 20 Nov 2020

Thanks @martin-koch for trying that.

I am checking the source code, and I am trying to understand from where the CMAKE_SYSROOT=/usr/aarch64-linux-gnu comes from.

Apparently Conan is not setting it, so it might be one of your dependencies that is setting in its package_info() defining self.cpp_info.sysroot = "/usr/aarch64-linux-gnu". Is it possible? Are you using that sysroot information elsewhere that you need it defined?

memsharded on 20 Nov 2020

I suppose it's from these:

            if self._conanfile and self._conanfile.deps_cpp_info.sysroot:
                sysroot_path = self._conanfile.deps_cpp_info.sysroot
            else:
                sysroot_path = os.getenv("CONAN_CMAKE_FIND_ROOT_PATH", None)

as profile set

[env]
CONAN_CMAKE_FIND_ROOT_PATH=/usr/$toolchain

SSE4 on 20 Nov 2020

@SSE4 is right. If i delete the CONAN_CMAKE_FIND_ROOT_PATH entry it works as well.
Isn't it required to set this environment variable? Since all cross build examples are setting it...

martin-koch on 20 Nov 2020

IMO it's a bit confusing and misleading - I expected CONAN_CMAKE_FIND_ROOT_PATH converts directly into CMAKE_FIND_ROOT_PATH cmake definition. and I think it's according to the documentation. setting CMAKE_SYSROOT from CONAN_CMAKE_FIND_ROOT_PATH is weird, why not use CONAN_CMAKE_SYSROOT for that? since these two CMake variables have different meaning and different effects:

CMAKE_SYSROOT basically converts into --sysroot compiler flag (affects on how compiler finds headers and libraries)
CMAKE_FIND_ROOT_PATH affects CMake functions, such as find_package, find_library and so on.

SSE4 on 20 Nov 2020

After updating from conan 1.29.1 to 1.31.3 all my cross build scenarios fails.
After downgrading conan to 1.29.2 all my cross build scenarios works again like supposed.

cmake version 3.19.0
Python 3.8.5
OS: Win 10

My profile configuration

target_host=x86_64-none-linux-gnu

cc_compiler=x86_64-none-linux-gnu-gcc
cxx_compiler=x86_64-none-linux-gnu-g++

[env]
CONAN_CMAKE_FIND_ROOT_PATH=C:x86_64-none-linux-gnubin
CHOST=$target_host

AR=C:x86_64-none-linux-gnux86_64-none-linux-gnubinar
AS=C:x86_64-none-linux-gnux86_64-none-linux-gnubinas
RANLIB=C:x86_64-none-linux-gnux86_64-none-linux-gnubinranlib
STRIP=C:x86_64-none-linux-gnux86_64-none-linux-gnubinstrip

CC=x86_64-none-linux-gnu-gcc
CXX=x86_64-none-linux-gnu-g++

[settings]
os_build=Windows
arch_build=x86_64

os=Linux
arch=x86_64

compiler=gcc
build_type=Debug
compiler.libcxx=libstdc++11
compiler.cppstd=14
compiler.version=6

AlexGoMobile on 22 Nov 2020

Hi @AlexGoMobile

Yes, it seems that it was a bug fix that it was only half-baked.

Before, for those scenarios, the CMAKE_SYSTEM_NAME was not being set. This was reported as a bug, and fixed.
Now, it seems that some other variables are not correctly set, and that is making things fail.
If you could try some of the suggestions above, to see what would be the most correct solution:
- Add the variables, like cmake.definitions["CMAKE_SYSTEM_PROCESSOR"] = "x86_64" and cmake.definitions["CMAKE_HOST_SYSTEM_NAME"] = "Windows", to see if that fix.
Please enable the log.run_to_output configuration, and copy here the build commands with 1.29.2 and 1.31, so we can check the differences.

We would prefer to move forward with the fix, instead of having to revert something that still reads like a bugfix (CMAKE_SYSTEM_NAME not being defined for cross-builds), so having more information of what is necessary to make it work will really help, thanks!

memsharded on 22 Nov 2020

I have been tracking down the definition of sysroot_path = os.getenv("CONAN_CMAKE_FIND_ROOT_PATH"), it dates back to 2017, Conan 0.22: https://github.com/conan-io/conan/pull/1181/files

I would probably try removing it from Conan automatic definitions, it seems one of the things that is making things fail. Can you @AlexGoMobile please try also removing that definition in case you had it defined?

memsharded on 22 Nov 2020

8097 PR suggest to remove definition of sysroot from CONAN_CMAKE_FIND_ROOT_PATH, and passes tests (https://conan-ci.jfrog.info/blue/organizations/jenkins/ConanTestSuite/detail/PR-8097/1/pipeline)

memsharded on 23 Nov 2020

Hi @AlexGoMobile @martin-koch

Asking also for help and feedback if possible from some other people cross-compiling: @jasal82, @ericLemanissier, @a4z, @sztomi.

Let me summarize:

We fixed a bug in Conan 1.29, and the CMake build helper started to add CMAKE_SYSTEM_NAME for cross-compile scenarios.
As a result some users build have started to break. We have taken some actions, like not considering 64->32 bits really cross build for 'Windows', 'Linux', 'SunOS', 'AIX' systems. (OSX doesn't seem to be a case anymore).
Still some build break. PR #8097 removes the automatic definition of CMAKE_SYSROOT from CONAN_CMAKE_FIND_ROOT_PATH (and introduce CONAN_CMAKE_SYSROOT to define it explicitly).

I would really love if you could check that #8097 is working and doesn't break things, before releasing a new Conan 1.31.4 that will be broken again.

It is possible that some builds need to define CMAKE_SYSTEM_PROCESSOR, as https://github.com/conan-io/conan/pull/8026 is proposing. But that is probably a very early proof of concept, that might break other builds by defining processor architectures directly from Conan settings that are not recognized. In case you need to define CMAKE_SYSTEM_PROCESSOR for your builds to pass (and you are not setting it explicitly, which has always been possible via CONAN_CMAKE_SYSTEM_PROCESSOR), it would be great to know the correct values.

Thanks very much for your help!

memsharded on 23 Nov 2020

is it enough to clone the conan-io:release/1.31 branch, adopt the path that the conan file there can be found before that one in the system, and then run my helpers to rebuild my world?
or is there a different recommended procedure to test pr releases ?

a4z on 23 Nov 2020

Probably the easiest way is:

Clone the repo and checkout the release/1.31 branch. Make sure to pull latest changes
Install it with pip install -e .. This will execute the pip install but using the current repo as editable, so you can execute with the source as usual (running conan ... will execute that code from that branch)
If you don't want to mess with your current environment, maybe creating a new python virtualenv is a good thing, but not strictly necessary (I only keep 1 virtualenv for dev, and switching branches, etc., works pretty reliably)

memsharded on 23 Nov 2020

@memsharded: Suggested solution #8097 is working for my use case.

martin-koch on 24 Nov 2020

👍1

or is there a different recommended procedure to test pr releases ?

Hi @a4z, for me, a very handy way of testing that is creating a virtual environment and the installing with: pip install git+git://<repo>@<branch>

In this case, as the PR was already merged to the release branch:

pip install git+git://github.com/conan-io/conan.git@release/1.31

czoido on 24 Nov 2020

I have built successfully several packages for android and ios, using Conan version 1.31.4 (must be that mentioned branch)

a4z on 24 Nov 2020

I have built successfully several packages for android and ios, using Conan version 1.31.4 (must be that mentioned branch)

Excellent, thanks very much @a4z !

memsharded on 24 Nov 2020

Verified the branch against some arm cross builds. Seems to work fine.

Just for your information: We used to rely on the environment settings exposed by openembedded environment setup script (as generated by the Yocto SDK builds) to forward the required compiler settings to Conan and CMake. However, we ran into more and more problems with that approach because a lot of third party software (like e.g. Amazon AWS) use execute_process to spawn subordinate CMake builds for transitive dependencies which sometimes doesn't forward the environment settings properly. So in the end we decided to always generate CMake toolchain files for cross compilation cases (by manually generating them from the setting in the openembedded setup script) because that is the 'natural' way of injecting toolchains into CMake. So from our point of view I'd recommend to not use CC, CXX etc. settings in [env] section at all.

jasal82 on 24 Nov 2020

👍1

At the moment I can't quickly switch to a different conan version, but we are mostly using our own helpers (predating the upstream ones), so I don't think this will cause problems for us.

sztomi on 24 Nov 2020

👍1

Ok, thanks very much all for the feedback!!! :) :) :)

Lets move with #8097 for Conan 1.31.4, and we will keep working from there (please @AlexGoMobile, it would be great if you could update when it is released and try)

memsharded on 24 Nov 2020

Was this page helpful?

0 / 5 - 0 ratings