Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cross-compiling on conda-forge is trying to compile a wrong file #560

Open
mattip opened this issue May 16, 2024 · 3 comments
Open

cross-compiling on conda-forge is trying to compile a wrong file #560

mattip opened this issue May 16, 2024 · 3 comments

Comments

@mattip
Copy link

mattip commented May 16, 2024

Over at conda-forge/ray-packages-feedstock#158 I am trying to get ray which is using bazel5.4 to build for macos. The build machine available in CI is x86_64. When the target is x86_64 everything works. Bug when the target is arm64 (using a --crosstool_top bazel directive), I am seeing the build tries to compile boost/libs/context/src/asm/jump_x86_64_sysv_macho_gas.S which of course cannot succeed since the assembly in that file is for x86_64, not arm64. Conda-forge is a framework that sets up the CI environment, downloads the source code of the project, then runs a script to call the project's build system, in this case ray's source code and using python setup.py which calls bazel to build the project. Here is where this project comes into play:

    auto_http_archive(
        name = "com_github_nelhage_rules_boost",
        # If you update the Boost version, remember to update the 'boost' rule.
        url = "https://github.com/nelhage/rules_boost/archive/57c99395e15720e287471d79178d36a85b64d6f6.tar.gz",
        sha256 = "490d11425393eed068966a4990ead1ff07c658f823fd982fddac67006ccc44ab",
    )

which is then loaded as boost_deps, and then boost is used in other places in the bazel build script, for instance here

Any hints as to what might be going on? Do I need to define something to convey the target CPU to boost? I see the the conda-forge boost feedstock uses ARCHITECTURE=arm in the b2 call, is there something like that needed here?

@nelhage
Copy link
Owner

nelhage commented May 22, 2024

Hm, we select the assembly based on the platform here:

rules_boost/boost.BUILD

Lines 109 to 113 in 5d04542

":linux_x86_64": [
"libs/context/src/asm/jump_x86_64_sysv_elf_gas.S",
"libs/context/src/asm/make_x86_64_sysv_elf_gas.S",
"libs/context/src/asm/ontop_x86_64_sysv_elf_gas.S",
],

:linux_x86_64 is defined here:

rules_boost/boost.BUILD

Lines 34 to 40 in 5d04542

config_setting(
name = "linux_x86_64",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:x86_64",
],
)

Bazel documentation suggests that you might need to pass --platforms to the Bazel build? I'm not actually that familiar with how Bazel platforms and cross-compilation work, offhand.

@mattip
Copy link
Author

mattip commented May 23, 2024

I forget to say I am have build --cpu=darwin_arm64 in my .bazelrc, which should have prevent setting the linux_x86_64 config_setting. Do you have any tips how to debug the config_setting used in the build? Is there some kind of print I can use in bazel to add debug info?

@nelhage
Copy link
Owner

nelhage commented May 23, 2024

With the continued caveat that I don't closely follow bazel targets/cross-compilation, the docs make it look to me like --cpu and --platforms are somewhat independent and they're in the middle of a migration from the one to the other. So you may need both?

Bazel Starlark does have a print function you can try to use… You can check out a local copy of rules_boost and reference it with local_repository to experiment with adding debug prints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants