Arch Linux User Repository

There has been a recent influx of users reporting that they are encountering an error related to missing libcrypt.so.1:

error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

If you encounter this error, the issue is that your shell has not imported /etc/profile.d/google-cloud-sdk.sh, causing the CLOUDSDK_PYTHON environment variable (among others) to not be set. This causes the tool to use a bundled python executable with its own library searching logic which fails to find the correct library.

libcrypt is provided by core/libxcrypt, which is required by core/python, which is required by aur/google-cloud-sdk. If you've installed this package, you have the correct library.

This is not a bug with the package; it is a bug with your shell. At the moment, this appears to be limited to users of fish. Please check the wiki for information about the tasks you should perform when setting fish as your default shell to avoid errors like this.

Note: I overhauled my internal CI process that updates packages and syncs them out to external destinations (like the AUR). Please open an issue using the issue tracker if you encounter any issues.

@sudoforge @ginjiruu I received the same error in bash and fixed by installing https://archlinux.org/packages/core/x86_64/libxcrypt-compat/ as described here https://bbs.archlinux.org/viewtopic.php?pid=2022246#p2022246 (but now in community rather than aur) due to dropping libcrypt.so.1 from glibc.

@sudoforge export CLOUDSDK_PYTHON=$(which python3) also fixed it for me on zsh. Thanks!

To those curious: ginjiruu was using fish, which apparently doesn't source /etc/profile, causing the CLOUDSDK_PYTHON variable to be unset (among other important variables). Specifically, when CLOUDSDK_PYTHON is unset, gcloud uses a vendored python3 executable, which wasn't linked appropriately.

I will likely remove this bundled python in future releases.

@ginjiruu Please open an issue using the issue tracker, and I'll follow up with you today to debug this issue specific to your environments.

@sudoforge I don't believe so. Was able to build version 371 just fine with the same shell config. First system tried was a local arch installation and the other was a wsl2 install that also succeeded on version 371 and is also having issues now

@ginjiruu This does not occur in a clean chroot, nor on my local system (outside of a chroot). Are you building this in a python virtual environment, or do you otherwise have a python virtual environment active in the shell session you are attempting to build it in?

Edit: And to be clear, you are encountering this error when building the package on your systems (as opposed to encountering it when running commands), correct?

Version 372.0.0-1 is giving me the error

/opt/google-cloud-sdk/platform/bundledpythonunix/bin/python3: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

despite having the various ssl packages installed. Repeated on 2 separate computers.

@rsaxena correct, 371.0.0-4 updates the patch to cover a new use of collections.Mapping that was introduced in 370.0.0 and missed (because my pipeline does not test every possible command; although this is something I'm aiming to resolve in the upcoming weeks).

Somewhat hilariously, 370.0.0 actually introduced the removal of a workaround to support the collections -> collections.abc change for newer versions of Python.

➜ diff {369,370}/platform/bq/bigquery_client.py | head -10
--- 369/platform/bq/bigquery_client.py    1980-01-01 01:00:00.000000000 -0700
+++ 370/platform/bq/bigquery_client.py    1980-01-01 01:00:00.000000000 -0700
@@ -58,9 +58,6 @@

 _GCS_SCHEME_PREFIX = 'gs://'

-collections_abc = collections
-if sys.version_info > (3, 8):
-  collections_abc = collections.abc