[3.8] Build against libxcrypt on Linux

[mbargull]

refs:

• Build against libxcrypt on Linux #664
• unbundle libcrypt linux-sysroot-feedstock#52

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[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) and found it was in an excellent condition.

[mbargull]

gh-664 was merged, so I'm putting in the version-branched PRs as well.

[jakirkham]

Do we need to add this to requirements/run as well? Or should libxcrypt have run_exports?

Asking because of issues like this one: conda-forge/ray-packages-feedstock#150 (comment)

cc @h-vetinari

[mbargull]

John, I really don't understand why these kinds of questions come up.
It would be trivial for you to check whether libxcrypt had run_exports.

[jakirkham]

That's not the question though

The question is why we are still needing to work around this in packages:

• ray-packages v2.9.3 ray-packages-feedstock#150 (comment)
• Rebuild for CUDA 12 w/arch support torch-scatter-feedstock#25 (comment)

[mbargull]

That's not the question though

That was literally the question you asked.

The question is why we are still needing to work around this in packages:

If you have downstream builds that do not find headers/libraries then the first thing to check is whether those builds respect the CFLAGS/CXXFLAGS/LDFLAGS we provide.

[jakirkham]

Hey Marcel, I'm sorry if I've said something that offended you. That was not my intent 😞

Agree that is a good thing to check 👍

Am mentioning this as we are actually seeing a few cases where users were able to build Python extensions ok (so presumably they got Python headers without issues before). However when it comes to crypt.h or -lcrypt they are running into issues:

• torchmd-net v0.15.2 torchmd-net-feedstock#21 (comment)
• enable arm64 builds libtiledb-sql-py-feedstock#17 (comment)

While it certainly could be flag issues, I'm curious how they are able to find other things like Python.h, but not crypt.h. Would be interested in hearing your insights

[isuruf]

While it certainly could be flag issues, I'm curious how they are able to find other things like Python.h, but not crypt.h. Would be interested in hearing your insights

Can you check whether Python.h and crypt.h are in the same location? Then you should have your answer.

[mbargull]

Hey Marcel, I'm sorry if I've said something that offended you. That was not my intent 😞

Oh, don't worry no offense taken.
(In case my use of "literally" came over as harsh: I meant its literal ( 😆 ) sense -- not in the often encountered hyperbolical misuse!)

The issue is just that such things grab the attention of some(/multiple) of our most valued members (maintainers of python package/core members) and as such tap into important/scarce resources of ours -- which I'd like us not to do if it can be avoided by doing some quick checks beforehand (which I'd kind of expect from seasoned members like yourself).

---

As Isuru hinted at, Python.h is not located directly under the main include directory; as such builds which only include paths to Python.h's directory won't find other headers.
(The reason that only 3.8 builds are affected is just that later versions don't include config.h in Python.h.)
Mind you, it is actually a good thing that these builds failed then; it gives you an indication that other flags (e.g., CPU arch) that we'd want to use for our packages are left out, too.

[jakirkham]

Ok fair enough

My point is more that we are seeing recurring issues with a security fix where maintainers are frequently throwing up their hands and linking to issue ( conda-forge/linux-sysroot-feedstock#52 ) with various hacks they had to implement. So am concerned something isn't work right (am not claiming to know what it is yet and it may not just be one thing), but the nature of these problems does merit more attention

(The reason that only 3.8 builds are affected is just that later versions don't include config.h in Python.h.)
Mind you, it is actually a good thing that these builds failed then; it gives you an indication that other flags (e.g., CPU arch) that we'd want to use for our packages are left out, too.

Ah ok! This is the sort of insight I was hoping for. Thanks Marcel! 🙏