Arch Linux User Repository

@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

With the new patch (v. 371.0.0-4) it is working for me, Python 3.10.2

The current version is failing with Python 3.10.1:

└─[$] bq
Traceback (most recent call last):
  File "/opt/google-cloud-sdk/platform/bq/bq.py", line 63, in <module>
    import bigquery_client
  File "/opt/google-cloud-sdk/platform/bq/bigquery_client.py", line 6755, in <module>
    class ApiClientHelper(object):
  File "/opt/google-cloud-sdk/platform/bq/bigquery_client.py", line 6761, in ApiClientHelper
    class Reference(collections.Mapping):
AttributeError: module 'collections' has no attribute 'Mapping'
└─[$] python -V
Python 3.10.1

I will investigate more later and provide details if I find the reason.