ensure other sysroots in same env respect version as lower bound#87
ensure other sysroots in same env respect version as lower bound#87h-vetinari wants to merge 2 commits intoconda-forge:mainfrom
Conversation
…nda-forge-pinning 2025.07.09.18.19.47
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe/meta.yaml:
Documentation on acceptable licenses can be found here. This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/16180992707. Examine the logs at this URL for more detail. |
| run: | ||
| - {{ pin_subpackage('kernel-headers_' ~ cross_target_platform, exact=True) }} | ||
| - tzdata | ||
| run_constrained: |
There was a problem hiding this comment.
This will probably need a repodata as otherwise, we will fallback to other build numbers, right?
Also, wouldn't it make sense to have a single sysroot_linux_mutex package to also cover the case where we add new architectures (like RISC-V)? All sysroot_linux-* packages would depend on it, and thus it would ensure consistency without the need for explicitly listing architectures here?
There was a problem hiding this comment.
Fine with other designs, though I don't really see the "mutually exclusive" aspect, neither for the sysroots (i.e. the can be co-installed), nor for the versions (it's just a lower bound).
And yes, with this approach it's possible that we need repodata patches, but that doesn't seem scary.
OK cool. Would you mind rebasing that PR, or do you want me to do it? |
Also, if you wouldn't mind explaining, I'd be curious what the use-case is for needing an older sysroot in |
|
#88 / #89 worked, as seen in conda-forge/nodejs-feedstock#405. Closing |
In conda-forge/nodejs-feedstock#397 we have a situation where we require glibc 2.28 as a lower bound, and
sysroot_linux-aarch64 2.28gets pulled in correctly into the build environment.However, we're getting
in the build environment, which ends up breaking compilation, because the build needs to compile something for the build-native architecture (i.e. seen from
$BUILD_PREFIX/bin/x86_64-conda-linux-gnu-c++ ...being called), which then fails due to the too-low glibc-version.I think it would be good if we could add constraints for the sysroots of other architectures to the packages here, so that setting
c_stdlib_versiononce ensures that all others respect that as a lower bound as well.If we can agree on this, I'm happy to backport this to 2.28.