cpp_info is not being propagated correctly when using a private requirement in cross compile mode

[smoofra]

trafficstars

cpp_info is not being propagated correctly when using a private requirement in cross compile mode.

Here is example source to reproduce the issue

Environment Details

• Mac OS 12.3.1
• Conan 1.48.1
• Python 3.9.12

Steps to reproduce

In my example libfoo is a static library, and quux is an executable that requires it, using a private requirement. If I try to build quux in cross-compile mode, libfoo's information disappears from quux's cpp_info and it can no longer find foo.h

git clone https://github.com/smoofra/conan-bug.git
cd conan-bug
conan create -pr ./Macos-armv8 libfoo

# this works
conan create -pr ./Macos-armv8 quux

# but this fails
conan create -pr:h ./Macos-armv8 -pr:b ./Macos-armv8 quux

expected error:

cc -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -arch arm64 -DNDEBUG   quux.c -lfoo -o quux 
quux.c:3:10: fatal error: 'foo.h' file not found

[jcar87]

Hi @smoofra - thanks for raising the issue and for using the new build and host profile conventions in conan, and for making a repository available where it was easy to replicate the issue.

Based on my testing, the issue appears related to the usage of the host and build profiles (passing the --profile:build and --profile:host to conan create, and the AutoToolsBuildEnvironment build helper. In this case, we get the reported failure even when both build and host profiles have the same value (and thus, conan is not cross-compiling or at least is not aware of it).

I have had success using the newer Autotools integrations from conan 2.x (that are currently experimentally in Conan 1.49.0) (docs here):

from conans import ConanFile
from conan.tools.gnu import Autotools

class QuuxConan(ConanFile):
    name = "quux"
    version = "1.0"
    settings = "os", "compiler", "build_type", "arch"

    requires = [("libfoo/1.0", "private")]
    
    exports = ['Makefile', 'quux.c']

    generators = "AutotoolsToolchain", "AutotoolsDeps"

    def build(self):
        autotools = Autotools(self)
        autotools.make()

    def package(self):
        autotools = Autotools(self)
        autotools.install()

Please note that the use of the private flag when adding dependencies is discouraged in Conan 1.x as there have been corner cases with issues. This is resolved in Conan 2.0's new dependency model, where there are new ways to express dependency traits, you can read more about the rationale here.

As a side note and unrelated to the issue at hand: If you are on macOS on Intel and intend to cross-build to macOS for Apple Silicon, the conan create invocation should reflect two distinct profiles, for example:

conan create -pr:h macos-intel -pr:b macos-arm quux

Otherwise conan may not detect it is in cross-compilation mode and may not propagate the necessary flags to cause Apple Clang to emit code for the intended architecture. You can read more in the Profiles section of this blog post: https://blog.conan.io/2021/09/21/m1.html

[jcar87]

Hi @smoofra - any luck with the proposed solution? Please let us know if we can provide further assistance.

[memsharded]

Hi @smoofra

Any update here? I am moving this to next 1.52 iteration, please have a look at the above comments.

[kambala-decapitator]

conan 1.51.2 generated me (conan profile new default --detect) the following default profile:

[settings]
os=Macos
os_build=Macos
arch=x86_64
arch_build=x86_64
compiler=apple-clang
compiler.version=13
compiler.libcxx=libc++
build_type=Release
[options]
[build_requires]
[env]

Is it correct to cross-compile to arm64 simply with --settings:host=arch=armv8 (or even just --settings=arch=armv8)? At least it seems to produce correct binaries.

Or using 2 profiles is the only right way (or will become so in the future)?

And if I understand correctly, I can do the same with 2 profiles approach like this:

... --profile:build default --profile:host default --settings:host arch=armv8

[memsharded]

Is it correct to cross-compile to arm64 simply with --settings:host=arch=armv8 (or even just --settings=arch=armv8)? At least it seems to produce correct binaries.

It might still eventually work, depending on which build integrations you are using, the recipe, the build scripts, the environment, etc. But it is not the recommended way.

Or using 2 profiles is the only right way (or will become so in the future)?

Yes, conan 2.0 use always 2 profiles, and it has dropped os_build, arch_build settings. It is also the current recommended way, not using the 2 profiles is considered legacy and not maintained anymore.

[kambala-decapitator]

@memsharded thank you very much for the explanation! Now it's fully clear.

[jcar87]

Hi @kambala-decapitator - using the newer autotools integration (dos here) I can see this works correctly when cross-compiling using two profiles. Will be closing this issue, but please feel free to reopen if there are any further concerns.