[bug] Conan setting `CMAKE_FIND_ROOT_PATH_MODE_*=BOTH` fundamentally breaks cross-compilation about conan HOT 4 OPEN

Hi @tttapa

Thanks for your report.

Can you please clarify what Conan version are you using?

Conan 2 sets only:

        {% if build_paths %}
        # The explicitly defined "builddirs" of "host" context dependencies must be in PREFIX_PATH
        list(PREPEND CMAKE_PREFIX_PATH {{ build_paths }})
        {% endif %}
        {% if cmake_program_path %}
        list(PREPEND CMAKE_PROGRAM_PATH {{ cmake_program_path }})
        {% endif %}

from the build context, should this 2 variables CMAKE_PREFIX_PATH or CMAKE_PROGRAM_PATH make the find_library() find a library in the build context?

from conan.

Hi, I'm using version 2.3.1.

At first sight, the code you posted looks fine, the problematic lines are further down:

Looking at the git blame, the last change to this bit of code was two years ago in 861170c.

from conan.

If I remember correctly, if CMAKE_FIND_ROOT_PATH_MODE_{LIBRARY,INCLUDE,PACKAGE} is set to ONLY, and there is a CMAKE_SYSROOT defined, none of the calls to find_package/find_library/find_program will work to locate anything provided by Conan - the entire search path, incl. CMAKE_PREFIX_PATH and so on, will be re-rooted to the sysroot), and none of the relevant locations will actually be considered.

If a user explicitly sets CMAKE_FIND_ROOT_PATH_MODE_{LIBRARY,INCLUDE,PACKAGE}=ONLY in their toolchain file, it is often for good reasons, and IMHO silently changing those values inside of Conan's toolchain file is not an acceptable solution.

I could agree that if the variable is already defined with an ONLY, we could warn - either honour it and expect CMake to not find anything provided by conan (the user can provide their own toolchain to work that out if they wish), or warn the user to set it to both.

The only case where I could see this working properly is when the only package provided by conan is the sysroot itself, and the sysroot contains everything and no individual libraries are provided as conan packages.

The provided example is fine and valid, but in the situation described, both are an error for find_library(LIBREADLINE "libreadline.so")

• if it is not in the sysroot, error out early (the desired outcome)
• if it found in the build machine, it will error out late (and attempt a link against the wrong one)

Obviously I can see how erroring out early is much preferable, as it would point you to arrive at the solution sooner - but once the underlying problem is addressed (libreadline.so is present in the sysroot), it will work correctly even with the current Conan behaviour.

from conan.

If I remember correctly, if CMAKE_FIND_ROOT_PATH_MODE_{LIBRARY,INCLUDE,PACKAGE} is set to ONLY, and there is a CMAKE_SYSROOT defined, none of the calls to find_package/find_library/find_program will work to locate anything provided by Conan - the entire search path, incl. CMAKE_PREFIX_PATH and so on, will be re-rooted to the sysroot), and none of the relevant locations will actually be considered.

This is true, but only because Conan does not currently set CMAKE_FIND_ROOT_PATH.

The provided example is fine and valid, but in the situation described, both are an error for find_library(LIBREADLINE "libreadline.so")

• if it is not in the sysroot, error out early (the desired outcome)
• if it found in the build machine, it will error out late (and attempt a link against the wrong one)

No, this is not a given. For example, I'm in a situation where I'm cross-compiling with build=x86_64-linux-gnu and host=x86_64-linux-gnu, but they're different systems with different Linux distributions, different toolchains, and different versions of glibc etc. Even though it may happen to link without errors, linking to binaries from the build system will still result in binaries that do not run once deployed on the host system. Or even worse: it may appear to run correctly in most cases, but ABI incompatibilities or ODR violations cause it to crash sporadically or make it exploitable to bad actors.

Second, when cross-compiling, one often prepares a sysroot with specific versions of packages. If for some reason, CMake is unable to find the intended package in the sysroot (e.g. because of a typo in the paths provided by the user), or it is unable to find the Conan-provided package, CMake should should fail, not silently link to a random version of the package it picked up in a /opt/side-projects/thirdparty/libfoo-master folder that happened to be in the build system's PATH.

from conan.