virtual packages: cross-compiling packages for glibc 2.17

[milahu]

i am trying to build rqbit with rattler-build
(see also my rqbit/run.sh script)
but the package fails to install because it still requires glibc 2.39

my build machine has glibc 2.42
my target machine has glibc 2.24

build $ ldd --version | head -n1 | sed 's/^.* //'
2.42

target $ ldd --version | head -n1 | sed 's/^.* //'
2.24

conda-forge has sysroot_linux-64 2.17

build for glibc 2.17

so i tried to build rqbit for glibc 2.17
by setting CONDA_OVERRIDE_GLIBC=2.17

CONDA_OVERRIDE_GLIBC=2.17 rattler-build build --variant-config variant_config.yaml --recipe rattler-build.sh recipes/rqbit/recipe.yaml

variant_config.yaml

c_stdlib:
  - sysroot

c_compiler:
  - gcc

and the built package seems to depend on glibc 2.17

unzip output/linux-64/rqbit-9.0.0_beta.2-h00ff4ad_0.conda
tar xf info-rqbit-9.0.0_beta.2-h00ff4ad_0.tar.zst
cat info/index.json | jq .depends

[
  "libgcc >=15",
  "__glibc >=2.17,<3.0.a0",
  "openssl >=3.6.3,<4.0a0"
]

install fails

but when i try to install this package on my target machine
then the installation fails with

$ micromamba install -c file://$PWD/output -c conda-forge --yes rqbit
...
Resolving Environment
error    libmamba Could not solve for environment specs
    The following package could not be installed
    └─ rqbit =* * is not installable because it requires
       └─ __glibc >=2.39,<3.0.a0 *, which is missing on the system.
critical libmamba Could not solve for environment specs

so it seems like the rqbit package still depends on glibc 2.39 (but why...?)

same artifact ID

coming from nix, what is also confusing is that
i always get the same artifact ID h00ff4ad in
output/linux-64/rqbit-9.0.0_beta.2-h00ff4ad_0.conda
but i would expect to get a different ID for different input specs
aka input-addressed store (like with nix)

related but not helpful

• Deep Dive: Virtual Packages and Archspec
• ae0c9c0
• conda/rattler@8c87c54
• Conda glibc dependency conflict
• How to override system-level characteristics in Conda solve?
• Managing virtual packages (conda docs)
• CentOS sysroot for linux-* Platforms (conda-forge docs)
• Including GLIBC in a conda package
• How to resolve glibc errors in conda enviroment installation?

[wolfv]

I believe you need to also set c_stdlib_version to 2.17 and use the ${{ stdlib('c') }} package in your build requirements. Did you try that?

The virtual packages that you are pointing out are serving a slightly different use case here.