-
-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fedora 35(x64), error while loading shared libraries: libcrypt.so.1 #113
Comments
Note that there is prior history with It is still an unsolved problem. I suspect that in the wild a lot of users have FWIW in Fedora 35, I'll repeat what I said in the old PyOxidizer issue that the Linux Standard Base Core Specification defines The reason this matters is because the LSB defines an interface that projects like this can target with reasonable guarantees of cross-distro compatibility. And by not conforming with the LSB, Fedora is essentially foregoing that compatibility. From my perspective, my preference would be for Fedora to be compliant with the LSB Core Specification and provide a An alternative solution is to provide a Python build that doesn't depend on At the very least we should document this quirk and its current workaround. |
On audit of the If CPython were relying on functions not defined by the LSB, that would be grounds to remove the functionality. But since the functions it uses are defined by the LSB Core Specification, I don't believe CPython or this project are in the wrong in their dependence on |
See also pantsbuild/pants#7369 (comment) and https://patchwork.ozlabs.org/project/glibc/patch/20170829184247.6875-1-zackw@panix.com/. It looks like glibc deprecated libcrypt back in 2017. So I guess glibc is the cause of Linux distros being incompatible with the LSB Core Specification?! Standards. 🤷♂️ |
If glibc did in fact delete libcrypt and distros are providing |
Filed https://bugzilla.redhat.com/show_bug.cgi?id=2055953 against Fedora and at this time they seem to acknowledge that this is a legit distro bug.
|
Looks like a fix was committed a few weeks ago. So closing this issue. Will also push a commit adding documentation about this quirk later today. |
Modern Linux distributions are starting to remove `libcrypt.so.1` from the base disto. See #173 and #113 before it for more context. The `_crypt` extension module depends on `libcrypt.so.1` and our static linking of this extension is causing the full Python distribution to depend on `libcrypt.so.1`, causing our binaries to not load/run on these distributions. This commit adds support for building extension modules as shared libraries (the way CPython does things by default). We update our YAML config to build `_crypt` as a shared library.
Modern Linux distributions are starting to remove `libcrypt.so.1` from the base disto. See #173 and #113 before it for more context. The `_crypt` extension module depends on `libcrypt.so.1` and our static linking of this extension is causing the full Python distribution to depend on `libcrypt.so.1`, causing our binaries to not load/run on these distributions. This commit adds support for building extension modules as shared libraries (the way CPython does things by default). We update our YAML config to build `_crypt` as a shared library.
Modern Linux distributions are starting to remove `libcrypt.so.1` from the base disto. See #173 and #113 before it for more context. The `_crypt` extension module depends on `libcrypt.so.1` and our static linking of this extension is causing the full Python distribution to depend on `libcrypt.so.1`, causing our binaries to not load/run on these distributions. This commit adds support for building extension modules as shared libraries (the way CPython does things by default). We update our YAML config to build `_crypt` as a shared library. As part of this we remove a patch to `makesetup` that was removing rules for emitting extension info to the generated `Makefile`. Git commit messages and my mental memory are a bit foggy on the history. But I want to say this patch had its origins in the very early days of this project when I was still trying to figure out how to get extension modules to statically link. The removed code created some contamination of the generated `Makefile` making it harder to grok behavior. I think that the presence of these additional variables and rules is safe and doesn't cause unwanted regressions. We have pretty strong validation of the built distributions - including ELF symbol visibility checks. So I'm optimistic this reintroduction won't cause problems. Closes #173.
Modern Linux distributions are starting to remove `libcrypt.so.1` from the base disto. See #173 and #113 before it for more context. The `_crypt` extension module depends on `libcrypt.so.1` and our static linking of this extension is causing the full Python distribution to depend on `libcrypt.so.1`, causing our binaries to not load/run on these distributions. This commit adds support for building extension modules as shared libraries (the way CPython does things by default). We update our YAML config to build `_crypt` as a shared library. As part of this we remove a patch to `makesetup` that was removing rules for emitting extension info to the generated `Makefile`. Git commit messages and my mental memory are a bit foggy on the history. But I want to say this patch had its origins in the very early days of this project when I was still trying to figure out how to get extension modules to statically link. The removed code created some contamination of the generated `Makefile` making it harder to grok behavior. I think that the presence of these additional variables and rules is safe and doesn't cause unwanted regressions. We have pretty strong validation of the built distributions - including ELF symbol visibility checks. So I'm optimistic this reintroduction won't cause problems. Closes #173.
Modern Linux distributions are starting to remove `libcrypt.so.1` from the base disto. See #173 and #113 before it for more context. The `_crypt` extension module depends on `libcrypt.so.1` and our static linking of this extension is causing the full Python distribution to depend on `libcrypt.so.1`, causing our binaries to not load/run on these distributions. This commit adds support for building extension modules as shared libraries (the way CPython does things by default). We update our YAML config to build `_crypt` as a shared library. As part of this we remove a patch to `makesetup` that was removing rules for emitting extension info to the generated `Makefile`. Git commit messages and my mental memory are a bit foggy on the history. But I want to say this patch had its origins in the very early days of this project when I was still trying to figure out how to get extension modules to statically link. The removed code created some contamination of the generated `Makefile` making it harder to grok behavior. I think that the presence of these additional variables and rules is safe and doesn't cause unwanted regressions. We have pretty strong validation of the built distributions - including ELF symbol visibility checks. So I'm optimistic this reintroduction won't cause problems. Closes #173.
Modern Linux distributions are starting to remove `libcrypt.so.1` from the base disto. See #173 and #113 before it for more context. The `_crypt` extension module depends on `libcrypt.so.1` and our static linking of this extension is causing the full Python distribution to depend on `libcrypt.so.1`, causing our binaries to not load/run on these distributions. This commit adds support for building extension modules as shared libraries (the way CPython does things by default). We update our YAML config to build `_crypt` as a shared library. As part of this we remove a patch to `makesetup` that was removing rules for emitting extension info to the generated `Makefile`. Git commit messages and my mental memory are a bit foggy on the history. But I want to say this patch had its origins in the very early days of this project when I was still trying to figure out how to get extension modules to statically link. The removed code created some contamination of the generated `Makefile` making it harder to grok behavior. I think that the presence of these additional variables and rules is safe and doesn't cause unwanted regressions. We have pretty strong validation of the built distributions - including ELF symbol visibility checks. So I'm optimistic this reintroduction won't cause problems. Closes #173.
Good project, thanks you for it.
Have a problem(subj).
When do what here proposed it starts working: missing-libcrypt-so-1-library-on-fedora
But the main goal to install everything without root privileges.
A bit more info: fedoraproject: Replace glibc libcrypt with libxcrypt
Is here can be any workaround? Or the only way is to build separate version for last two Fedora's?
The text was updated successfully, but these errors were encountered: