Closed sureshjoshi closed 7 months ago
Yeah, tests are definitely in play. That's in the slow path, so we can be elaborate in code to do the test. How you do that test robustly I have ~0 clues.
Like, CI tests? Or install-time tests?
I can think of a few kinda gross ones:
ldconfig
, which I think uses sudo (at least, on my machine it does)If we think the error string is a stable one, what about letting it fail and just adding a cleaner error message to the end?
Would be nicer to have that directly in PyOx or Standalone, but 🤷🏽
The only way I could imagine the error string not being stable is if Greg decided to suppress the output of the error for some reason, which seems unlikely.
Note: Might also be a problem for Arch-ers? https://unix.stackexchange.com/questions/691479/how-to-deal-with-missing-libcrypt-so-1-on-arch-linux
And to no-one's surprise, Greg's suggested workaround works:
sudo dnf install libxcrypt-compat
I mean install time tests, as I think you meant. Install is the slow path and it's ok to be slow and potentially complex there.
And yes, it's a problem for Arch. Despite my current Windows stint to bring Windows support to Pex, I'm a long time Arch user (2003+). It's rolling bleeding edge and tends not to have old libs installed by default. PyOx gave me issues last I tried it on arch w/o installing a back compat package.
@sureshjoshi, ldd python
should actually do it. I think ldd
is pervasive and it does not require root.
Didn't even think of ldd
, I always just assumed it came down with build essentials or whatever, but nope - it's there in my containers.
I think ldd
comes with libc/glibc?
musl
has that functionality built-in if memory serves, so I wonder how alpine
would work out? Not that alpine
should be a deal breaker, just typing out loud.
From: https://wiki.musl-libc.org/faq.html
musl’s dynamic linker comes with ldd functionality built in. Just create a symlink from ld-musl-$ARCH.so to /bin/ldd. If the dynamic linker was started as “ldd”, it will detect that and print the appropriate DSO information.
There currently is no scie-pants for Alpine (scie-pants itself is musl libc static, but no musl PBS CPython is configured).
Maybe you could add that support?
So, this was nominally fixed by @kaos in #311: https://github.com/pantsbuild/scie-pants/blob/3497f4cac1e1b93f9122c9160a153802762255ae/package/scie-pants.toml#L17-L29
But that upgrade only worked for science - which uses 3.11 from that release - 3.8 and 3.9 are still broken: https://github.com/indygreg/python-build-standalone/issues/197. That was fixed by this release though: https://github.com/indygreg/python-build-standalone/releases/tag/20240107; so scie-pants should likely upgrade.
Known issue from Python Standalone (https://github.com/indygreg/python-build-standalone/issues/113) and PyOx (https://github.com/indygreg/PyOxidizer/issues/89).
Ran into this in Fedora (environment detailed below). Will try Greg's workaround tonight when I'm home.
Suggestions
Since we use Python 3.9 standalone, some number of Red Hat users will run into this bug when using Pants. I'd recommend documenting this problem and linking back to Greg's documentation (https://github.com/indygreg/python-build-standalone/blob/main/docs/quirks.rst#missing-libcryptso1).
Alternatively/In addition - would it be worth checking for that missing library, and providing a clearer and/or more actionable warning on Linux?
Environment
Fedora 37 toolbox created in Fedora SilverBlue 37 host OS.