Drop outdated sysroot

[h-vetinari]

Something I descoped from #142 because AFAICT we either need to rebuild the sysroot-with-crypt for 2.17 without the track_features (here's a branch how this would look like; consists of rebasing v2.17 on the last commit before crypt-removal), or we'd need to do something like conda-forge/linux-sysroot-feedstock#68

[conda-forge-webservices]

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 (recipe/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

@isuruf, can you let me know how you'd like to proceed here? should I create a branch for the crypt stuff on the sysroot feedstock, or do you want to got the "get rid of the repodata hacks" route? (obviously doing the former doesn't rule out doing the latter later).

[h-vetinari]

@isuruf, given that we'll have to wait several more months at least to get rid of the sysroot hacks, would you be OK with me creating a v2.17_crypt branch in the sysroot feedstock (details in OP)?

[h-vetinari]

Ping @isuruf for how to proceed here.

[isuruf]

Let's create 2.17 packages with crypt in it.

[isuruf]

Can you send a PR to linux-sysroot-feedstock?

[h-vetinari]

I can, but it needs a new branch before the crypt removal (which would go well with the label we're already using). I can create it if you want.

[isuruf]

Can you send a PR against 2.17 branch? I can merge directly to a new merge.

[h-vetinari]

The 2.17 branch has advanced too far. We should branch off earlier. Take a look at the branch I've already created (on my own fork) that's linked in the OP.

[conda-forge-admin]

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 (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12921318586. Examine the logs at this URL for more detail.}

[h-vetinari]

After conda-forge/linux-sysroot-feedstock#73 & conda-forge/conda-forge-ci-setup-feedstock#373 we're getting closer here, but still running into an issue related to the cross-compilation sysroot for s390x.

At first I misread the CI failure for 3afde80 to be due to old_triplet, and removed that because we've been using the new cdt-names for a long time (so any rerendered recipe should be fine AFAICT):

• CDT builds have been defaulting to --single-sysroot for ~4.5 years (recently turned into the only supported option: conda-forge/cdt-builds@9820ca0)
• sysroot has been defaulting to conda since ~4.5 years as well: conda-forge/linux-sysroot-feedstock@b84f035; we stopped producing them completely since conda-forge/linux-sysroot-feedstock@83d10ab, though the 2.17 branch currently still creates sysroot-cos7-x86_64 outputs.
• pinning switched two months ago conda-forge/conda-forge-pinning-feedstock@48621d1, which came later because it needed conda-forge/cdt-builds@c32b7e7 & conda-forge/cdt-builds@dc270e4

Independent of the question of whether that's a worthwhile change (I think so) and whether we want to do it as part of this PR (no strong preference from my side), the following error still persists.

++$PREFIX/bin/x86_64-conda-linux-gnu-gcc -dumpmachine
qemu-s390x-static: Could not open '/lib/ld64.so.1': No such file or directory

That's despite the sysroot environment being created successfully, and QEMU_LD_PREFIX being set accordingly:

+++ micromamba create -p /opt/conda/envs/sysroot_linux-s390x --root-prefix /home/conda/.conda --yes --quiet --override-channels --channel conda-forge --strict-channel-priority sysroot_linux-s390x=2.34
+++ [...]
+++ export QEMU_LD_PREFIX=/opt/conda/envs/sysroot_linux-s390x/s390x-conda-linux-gnu/sysroot
+++ QEMU_LD_PREFIX=/opt/conda/envs/sysroot_linux-s390x/s390x-conda-linux-gnu/sysroot

and the fact that the sysroot definitely contains {lib -> lib64}/ld64.so.1 under that QEMU_LD_PREFIX.

Any ideas @isuruf @beckermr? My best guess is that the qemu-s390x-static we're repackaging somehow does not respect QEMU_LD_PREFIX.

[h-vetinari]

Wanted to check if newer sysroots somehow change anything. 2.28 didn't (aside from the fact that we have no builds with crypt, but GCC 14 should have worked), and for 2.34, we get

checking for s390x-conda-linux-gnu-gcc... $SRC_DIR/cf-compilers/bin/s390x-conda-linux-gnu-gcc
checking whether the C compiler works... no
configure: error: in `/home/conda/feedstock_root/build_artifacts/gcc_compilers_1737601096935/work/build':
configure: error: C compiler cannot create executables

Which is certainly a surprise for me, given that glibc 2.34 was released 3.5 years ago, and GCC 12-14 were all released after that.