cross-compiling ROOT on ARM given the root_base run exports

[kratsg]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

#128 in this PR from ~5 years ago, the v0 recipe got the following addition to the run section:

  run:
...
    # FIXME: Required to ensure a consistent etc/allDict.cxx.pch
    - {{ pin_compatible('libcxx', min_pin='x', max_pin='x') }}
    - {{ compiler('c') }}
    - {{ compiler('cxx') }}
    - {{ pin_compatible('xxhash', max_pin='x.x.x') }}
    - nlohmann_json
...

and the problem is that this ends up causing issues for downstream packages that both depend on root (and root_base) by pulling in both x86 and arm64 architectures (and compiler flags) at the same time -- such as seen with RooUnfold. The set of packages that conda pulls in looks to be

 │ ╭─ Resolving environments
 │ │ 
 │ │ Resolving build environment:
 │ │   Platform: linux-64 [__unix=0=0, __linux=6.11.0=0, __glibc=2.34=0, __archspec=1=zen2]
 │ │   Channels: 
 │ │    - file:///home/conda/feedstock_root/build_artifacts/
 │ │    - conda-forge
 │ │   Specs:
 │ │    - gcc_linux-aarch64 14.*
 │ │    - gxx_linux-aarch64 14.*
 │ │    - sysroot_linux-aarch64 2.17.*
 │ │    - cmake
 │ │    - make
 │ │    - cross-python_linux-aarch64
 │ │    - python 3.10.* *_cpython
 │ │    - root_base 6.36.4.*
 │ │ 
 │ │ ╭───────────────────────────────┬──────────────┬───────────────────────┬─────────────┬─────────────╮
 │ │ │ Package                       ┆ Version      ┆ Build                 ┆ Channel     ┆        Size │
 │ │ ╞═══════════════════════════════╪══════════════╪═══════════════════════╪═════════════╪═════════════╡
...
 │ │ │ _x86_64-microarch-level       ┆ 3            ┆ 3_zen2                ┆ conda-forge ┆    9.60 KiB │
...
 │ │ │ binutils_impl_linux-64        ┆ 2.45         ┆ default_hfdba357_104  ┆ conda-forge ┆    3.57 MiB │
 │ │ │ binutils_impl_linux-aarch64   ┆ 2.45         ┆ default_hc5fa074_104  ┆ conda-forge ┆    3.39 MiB │
 │ │ │ binutils_linux-64             ┆ 2.45         ┆ default_h4852527_104  ┆ conda-forge ┆   35.33 KiB │
 │ │ │ binutils_linux-aarch64        ┆ 2.45         ┆ default_h7726a90_104  ┆ conda-forge ┆   35.39 KiB │
...
 │ │ │ gcc_impl_linux-64             ┆ 14.3.0       ┆ he8b2097_16           ┆ conda-forge ┆   71.80 MiB │
 │ │ │ gcc_impl_linux-aarch64        ┆ 14.3.0       ┆ h25aa15c_16           ┆ conda-forge ┆   76.49 MiB │
 │ │ │ gcc_linux-64                  ┆ 14.3.0       ┆ h298d278_15           ┆ conda-forge ┆   28.15 KiB │
 │ │ │ gcc_linux-aarch64             ┆ 14.3.0       ┆ hc6a817b_15           ┆ conda-forge ┆   28.15 KiB │
...
 │ │ │ ld_impl_linux-64              ┆ 2.45         ┆ default_hbd61a6d_104  ┆ conda-forge ┆  708.54 KiB │
 │ │ │ ld_impl_linux-aarch64         ┆ 2.45         ┆ default_h27e1c4c_104  ┆ conda-forge ┆  768.94 KiB │
...
 │ │ │ libgcc                        ┆ 15.2.0       ┆ he0feb66_16           ┆ conda-forge ┆ 1018.36 KiB │
 │ │ │ libgcc-devel_linux-64         ┆ 14.3.0       ┆ hf649bbc_116          ┆ conda-forge ┆    2.94 MiB │
 │ │ │ libgcc-devel_linux-aarch64    ┆ 14.3.0       ┆ h8c5ef91_16           ┆ conda-forge ┆    2.23 MiB │
 │ │ │ libgcc-ng                     ┆ 15.2.0       ┆ h69a702a_16           ┆ conda-forge ┆   26.62 KiB │
...

and so on, and you can see that it's a clear mix of both architectures. I think, after talking briefly with @matthewfeickert offline and also running into a similar issue with conda-forge/pytensor-suite-feedstock#191 as well -- we need to remove compiler pins on the runtime dependencies by using the cxx-compiler meta-package instead as recommended by @h-vetinari.

Granted, I don't know what happened for getting ROOT 6.24 that required needing to add this in or what the FIXME particular relates to here (maybe @chrisburr remembers?) but it would be really good to unblock this moving forward to be able to move towards ARM computing.

Installed packages

n/a

Environment info

n/a

[h-vetinari]

we need to remove compiler pins on the runtime dependencies by using the cxx-compiler meta-package instead as recommended by @h-vetinari.

As I explained in the PR that solves the pytensor issue you linked, it'd be better to just rely on gxx / clangxx, which will save you the compiler activation that you want to avoid

[kratsg]

As I explained in the PR that solves the pytensor issue you linked, it'd not be better to just rely on gxx / clangxx, which will save you the compiler activation that you want to avoid

I'm a bit confused by this. A recipe like

  build:
    - ${{ compiler('c') }}
    - ${{ compiler('cxx') }}
    - ${{ stdlib('c') }}
    - cmake
    - make
    - if: build_platform != target_platform
      then:
        - cross-python_${{ target_platform }}
        - python
        - root_base
  host:
    - root_base
    - python

build:
  script:
    - cmake ${CMAKE_ARGS}  -S . -B build
    - cmake --build build --clean-first --parallel="${CPU_COUNT}"
    - cmake --install build

should work. But you're saying that instead of using the compiler and stdlib macros, that we should just depend only on gxx / clangxx instead (with the right conditionals added to select the right compiler for the right platform)?

[h-vetinari]

A recipe like [...] should work

A recipe like this cannot work if the root_base in build: (==x64) brings along an activated compiler for that platform as one of its dependencies (i.e. {{ compiler("cxx") }} in root_base which ends up being gxx_linux-64, by necessity of the architecture of the build platform), while simultaneously wanting to compile for some other host (the {{ compiler("cxx") }} for the consuming recipe that's correctly set up to gxx_linux-aarch64).

If root_base instead depended on gxx/clangxx, you won't get the conflicting activations in the build environment, because the root_base in build: will not drag along gxx_linux-64 anymore.

[matthewfeickert]

I won't be able to read all of conda-forge/conda-forge.github.io#2595 tonight given time constraints, but from #331 (comment), conda-forge/conda-forge.github.io#2595 (comment), and conda-forge/pytensor-suite-feedstock#194 (comment), my 2-minute takeaway is that the root_base run requirements

root-feedstock/recipe/recipe.yaml

Lines 166 to 169 in 63081ce

	# FIXME: Required to ensure a consistent etc/allDict.cxx.pch
	- ${{ compiler('c') }}
	- ${{ compiler('cxx') }}
	- ${{ stdlib("c") }}

should be changed to

        - if: not osx
          then: gxx
          else: clangxx

as gxx has gcc as a dependency.

(I don't understand why

root-feedstock/recipe/recipe.yaml

Line 169 in 63081ce

- ${{ stdlib("c") }}

is given as a run requirement in the first place but maybe @chrisburr can inform me.)

cc @conda-forge/root

[matthewfeickert]

It seems that PR conda-forge/compilers-feedstock#78 will be very important in the future, given conda-forge/conda-forge.github.io#2595 (comment).

[matthewfeickert]

(I don't understand why

root-feedstock/recipe/recipe.yaml

Line 169 in 63081ce

• ${{ stdlib("c") }}
  is given as a run requirement in the first place

This was added in ebaadaa in PR #245. I may be wrong, but my understanding is that ${{ stdlib("c") }} was only needed as a build dependency, so I don't think it needed to (ever?) exist as a host or run requirement.

[h-vetinari]

should be changed to

        - if: not osx
          then: gxx
          else: clangxx

This recipe (in contrast to pytensor) uses MSVC on windows. So unless there's a good reason to change, you should stay on that. On windows, there's currently no equivalent, so you could do

        - if: linux
          then: gxx
        - if: osx
          then: clangxx
        - if: win
          # no equivalent to "minimally activated" gxx/clangxx yet
          then: vs_${{ host_platform }}

[matthewfeickert]

Thanks @h-vetinari! This detail I had missed, and so that's very good to know moving forward.

Luckily(?) for us, root_base has skipped Windows builds

root-feedstock/recipe/recipe.yaml

Lines 41 to 42 in 63081ce

	skip:
	- win

since the creation of the root_base output in PR #56, which had

root-feedstock/recipe/meta.yaml

Line 171 in 4ef16bb

skip: True # [win]

but this will be relevant for other feedstocks we maintain.

Though maybe being fully explicit with

        - if: linux
          then: gxx
        - if: osx
          then: clangxx

is easier to read for maintenance and we should go for that anyway.

[matthewfeickert]

@conda-forge/root, my understanding is that even after we get PR #332 fixed up and in, to be able to have things like conda-forge/roounfold-feedstock#1 work we'll also need to update the global pinning to be able to make sure that only root_base versions with the minimally activated compilers as run requirements are used.

[vepadulano]

@matthewfeickert thanks for the work so far!

we'll also need to update the global pinning

No problem with that from my side. If that means opening a migration, I'll attempt doing that once this feedstock is ready.

[matthewfeickert]

I'm confused and so have asked on the conda-forge Zulip for help understanding the compiler and run requirements scenarios better: #general > Confusion on use of minimally activated compilers in recipes

[matthewfeickert]

@conda-forge/root can you please respond to #general > Confusion on use of minimally activated compilers in recipes @ 💬? I don't understand enough about this feedstock to comment on the statically linked clang question.