error while loading shared libraries: libcrypt-06cd74a6.so.2 on aarch64

[qstokkink]

[EDIT] tl;dr "official" workaround (posted below):

Copy the libcrypt library that is distributed with cx_Freeze, it is located in cx_Freeze/bases/lib.

---

I used Ubuntu 22.04 aarch64 to create a build, which also works on Ubuntu 22.04 amd64 with the same setup. However, when running a build produced on Ubuntu 22.04 aarch64 specifically I get the following error.

error while loading shared libraries: libcrypt-06cd74a6.so.2: cannot open shared object file: No such file or directory

• Platform information: Ubuntu 22.04
• OS architecture: aarch64
• cx_Freeze version: 7.2.3 (cx_Freeze-7.2.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl from pip)
• Python version: 3.10

My solution
To solve this, I had to do two things. First, copy libcrypt.so.1 into the local directory as libcrypt-06cd74a6.so.2:

cp /lib/aarch64-linux-gnu/libcrypt.so.1 libcrypt-06cd74a6.so.2

Second, I added the following to the build_exe include_files entry:

("libcrypt-06cd74a6.so.2", "lib/libcrypt-06cd74a6.so.2")

For now my solution works. However, I guess my approach is very fragile and I think it would be better if this got solved on your side.

[marcelotduarte]

I thought #2624 fixed this issue, but I cannot test it on ARM.
You can get the wheel to test from the build.

[qstokkink]

I just tested the wheel you linked (cx_Freeze-7.3.0.dev0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl) and I get error while loading shared libraries: libcrypt-06cd74a6.so.2: cannot open shared object file: No such file or directory again.

By the way, for reproduction, the way I test using GitHub Actions is roughly this (but actually here):

name: Build Cross Deb
on: workflow_dispatch

jobs:
  aarch64_job:
    runs-on: ubuntu-22.04
    name: Build on ${{ matrix.distro }} ${{ matrix.arch }}
    strategy:
      matrix:
        include:
          - arch: aarch64
            distro: ubuntu22.04
    steps:
      - name: Check-out repository
        uses: actions/checkout@v4
        with:
          submodules: 'true'
          fetch-tags: 'true'
      - uses: uraimo/run-on-arch-action@v2
        name: Compile aarch64
        id: runcmd
        with:
          arch: aarch64
          distro: ubuntu22.04
          githubToken: ${{ github.token }}
          dockerRunArgs: |
            --volume "${PWD}:/myproject"
          shell: /bin/sh
          install: |
            apt-get update -q -y
            apt-get install -q -y --allow-downgrades python3-pip
          run: |
            cd myproject
            python3 -m pip install --upgrade cx_Freeze-7.3.0.dev0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
            
            # Use cx_Freeze to make a build
            export PATH="/usr/local/bin:$PATH"
            ./mybuildscript.sh

            # Do a test run (Actions eats the output without the || true)
            timeout 10s ./executable || true

[marcelotduarte]

I checked your logs.
Your command https://github.com/qstokkink/tribler/actions/runs/11494791674/job/31992947667#step:5:19
And the resulting download and install https://github.com/qstokkink/tribler/actions/runs/11494791674/job/31992947667#step:5:228

So, use pip install --pre
The --upgrade force it to upgrade to a stable version.

[qstokkink]

For the actual run, I didn't remove the cx_Freeze from our requirements.txt (causing it to install 7.2.3). However, later on in the log (https://github.com/qstokkink/tribler/actions/runs/11494791674/job/31992947667#step:5:365), I overwrite it with the dev wheel. You can see it uninstalling 7.2.3 again:

  Processing ./cx_Freeze-7.3.0.dev0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
  Requirement already satisfied: tomli>=2.0.1 in /usr/local/lib/python3.10/dist-packages (from cx-Freeze==7.3.0.dev0) (2.0.2)
  Requirement already satisfied: filelock>=3.12.3 in /usr/local/lib/python3.10/dist-packages (from cx-Freeze==7.3.0.dev0) (3.16.1)
  Requirement already satisfied: packaging>=24 in /usr/local/lib/python3.10/dist-packages (from cx-Freeze==7.3.0.dev0) (24.1)
  Requirement already satisfied: setuptools<76,>=65.6.3 in /usr/local/lib/python3.10/dist-packages (from cx-Freeze==7.3.0.dev0) (75.2.0)
  Requirement already satisfied: patchelf>=0.14 in /usr/local/lib/python3.10/dist-packages (from cx-Freeze==7.3.0.dev0) (0.17.2.1)
  Installing collected packages: cx-Freeze
    Attempting uninstall: cx-Freeze
      Found existing installation: cx_Freeze 7.2.3
      Uninstalling cx_Freeze-7.2.3:
        Successfully uninstalled cx_Freeze-7.2.3
  Successfully installed cx-Freeze-7.3.0.dev0

This should already be sufficient. However, I'll make another run that is completely sterile so there is not even any mention of another version.

EDIT: Here is the "sterile" version without any overwrites and with --pre (diff): https://github.com/qstokkink/tribler/actions/runs/11513528319/job/32050393652

[qstokkink]

I had some spare time so I dedicated a repo to this https://github.com/qstokkink/cxFreeze2641 I have some odd results that I hope make sense to you (I'm not sure what to make of this). I installed cx_Freeze in two ways: one way errors out and one way works.

First method

The first method was to install the latest development build, as per the instructions in the README.md:

python -m pip install --force --no-cache --pre --extra-index-url https://marcelotduarte.github.io/packages/ cx_Freeze

This fails (https://github.com/qstokkink/cxFreeze2641/actions/runs/11531913003/job/32103146381) with the expected:

./build/exe.linux-aarch64-3.10/executable: error while loading shared libraries: libcrypt-06cd74a6.so.2: cannot open shared object file: No such file or directory

Second method

I also tried manually building.

mkdir custom_cx_freeze
cd custom_cx_freeze
  git clone https://github.com/marcelotduarte/cx_Freeze
  cd cx_Freeze
    python -m pip install --upgrade uv --disable-pip-version-check
    UV_RESOLUTION=highest uv pip install --system --upgrade -r requirements.txt -r requirements-dev.txt -r requirements-doc.txt
    uv pip install --system -e. --no-build-isolation --no-deps --reinstall
  cd ..
cd ..

This works (https://github.com/qstokkink/cxFreeze2641/actions/runs/11531949742/job/32103214597). I'm not sure what to make of this. Was the latest development wheel simply out of date?

[marcelotduarte]

The story is a bit long, but I'll make it short.
A few months ago, a bug started in conda-forge related to crypt, and a user found a way to get around it by installing an additional package. Later, this problem appeared with wheels made with manylinux. I could debug and solve both cases, but I couldn't test it on platforms like arm64.
The difference occurs because a library that was previously statically compiled into Python became dynamically linked with the advent of Python 3.13 and they (conda, manylinux) chose to do the same with previous versions.

I managed to test using 'run-on-arch-action' and saw that in the case of aarch64 the issue continues, but I can't debug.

I tried to use qemu/podman on my machine, but it got stuck on a file that it doesn't recognize as a dynamic library (not a dynamic executable). In the amd64 version it recognizes it, but in the arm64 version it doesn't, so I think the error may be related to patchelf, which, by the way, has been causing me some errors.

Was the latest development wheel simply out of date?

Yes, there was a change in permissions on github and I'm not able to generate them anymore and I haven't had time to research, given the priorities.

This works (https://github.com/qstokkink/cxFreeze2641/actions/runs/11531949742/job/32103214597). I'm not sure what to make of this.

Yes, this way it works, if you intend to run only on that machine or with the same packages installed.
For distribution, read this.

Until we can solve this, you must update your workaround. Copy the libcrypt library that is distributed with cx_Freeze, it is located in cx_Freeze/bases/lib.

[qstokkink]

Thanks for the info! I think I understand the problem now: the issue is the wheel build process. However, first things first, I updated my opening post to quote your recommended workaround.

So far, I've only tried to create a clean reproducible problem (feel free to copy the Action into your own CI, by the way). Now, do you want help with a solution? Or, would you rather fix this yourself.

---

EDIT: To prove that the wheel build is the culprit, I copied in your build-wheel.yml job and I can reproduce the failure when installing the resulting wheel. See https://github.com/qstokkink/cxFreeze2641/actions/runs/11540683211/workflow

[marcelotduarte]

If I tell you that the error is not where I thought it would be. I decided to install a VM (KVM/qemu), which is much slower than a container, to clear up a doubt and boom: it worked without problems. In other words, the problem is the emulation used. If you have a way to test it on a real machine or a VM to confirm. I have an idea of ​​how to fix it, avoiding using ldd to detect dependencies. I was already thinking about it, using patchelf for this too, but it has some bugs. So I'll have to test other options first.

[qstokkink]

The reason I posted this issue is because my project had an issue reported by a real user. So, technically, yes I have a way to confirm.

However, I'd rather avoid sending testing code to users. First, I'd like to see the uraimo/run-on-arch-action@v2 action pass. So far, that Action is the only way to realiably reproduce real user machine behavior.

I know aarch64 appears in a lot of dirt-cheap laptops. I'll look into acquiring one for testing. I ordered a Raspberry Pi 4 so that I can test this on real aarch64 hardware. It should arrive in a few days.