`GLIBC_2.38' not found error on Ubuntu 22.04

[sfrsfrsfr]

Describe the bug

this is more a wish than an actual bug report but i'd appreciate it if 22.04 could be supported.
i think this, glibc related, bug comment fits here as well, gitbutler

thx for looking into it

To Reproduce

autoortho
/usr/local/bin/autoortho_lin_1.3.3.bin: /lib/x86_64-linux-gnu/libm.so.6: version GLIBC_2.38' not found (required by /usr/local/bin/autoortho_lin_1.3.3.bin) /usr/local/bin/autoortho_lin_1.3.3.bin: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.38' not found (required by /usr/local/bin/autoortho_lin_1.3.3.bin)
/usr/local/bin/autoortho_lin_1.3.3.bin: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.36' not found (required by /tmp/onefile_26462_1761328660_516119/libexpat.so.1) /usr/local/bin/autoortho_lin_1.3.3.bin: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.38' not found (required by /tmp/onefile_26462_1761328660_516119/libexpat.so.1)

Expected behavior
being able to run autoortho

(please complete the following information):

• OS: Ubuntu 22.04 LTS
• XPlane Version: 12.2.1-r1-ab13dbf0
• AutoOrtho Version1.3.3
• Filesystem type ext4

[ProgrammingDinosaur]

Hi. Maybe for some reason you don't have that distro. Could you try installing it via apt-get?

[sfrsfrsfr]

glibc is the core system library libc6 and cannot be updated. Ubuntu 22.04 ships with 2.35.

Package: libc6
Status: install ok installed
Priority: required
Section: libs
Installed-Size: 13598
Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com
Architecture: amd64
Multi-Arch: same
Source: glibc
Version: 2.35-0ubuntu3.11

Are you able to compile autoortho for 'old' distro's like 22.04?

[ProgrammingDinosaur]

I'll check it out. I will try to find where is the distro version being pinned

[karlrado]

If this hasn't already been solved:

• Most of the advice on the net for situations like these is to upgrade the OS, with the justification of you're going to have to do it someday anyway and it will just get harder until you do. Not great advice, if it is hard to upgrade. Plus, it is reasonable for an app to support the last two Ubuntu LTS releases.
• It is possible to build the version of glibc you need in your own workspace. Presumably, you can set LD_LIBRARY_PATH in (only) the shell used to start AO to find your version. But it can be hard to build this library and this seems fragile and you may run into other incompatibilities.
• On the product side, the GitHub Actions build scripts mostly specify "ubuntu-latest" for the build environment. It is possible to modify this:
  • The Actions can be modified (by the repo owner) to build on multiple Linux platforms. For example, they can be modified to build on "Latest" and specific ones like 22.04.
  • The OP can fork this repo and then modify the Action scripts to do Linux builds on 22.04. Enable Actions processing on the fork and then trigger a build. You may have to read up on Actions to figure out how to trigger it. Sometimes you have to push a commit or enable explicit task starting, etc. The last time I did this on my fork I had to push a tag. Then, over time, keep your fork in sync with this one and run the actions again when you want something to install.

[mmaechtel]

@ProgrammingDinosaur:

Try setting the build system to either:

• Ubuntu 22.04, or
• Debian 12 (note: not Debian Stable, which is currently 13)

These distributions ship with an older GLIBC, which tends to work better and keep users on older Linux systems (myself included) happy. 🙂

BTW: Linux users can simply clone the GitHub repository and run the Python version directly. It works great for me and avoids any GLIBC-related issues. If you want to maintain a dedicated Python version just for this project, tools like pyenv make that easy.

[karlrado]

BTW: Linux users can simply clone the GitHub repository and run the Python version directly. It works great for me and avoids any GLIBC-related issues. If you want to maintain a dedicated Python version just for this project, tools like pyenv make that easy.

@mmaechtel Were you able to do this with a Python release < 3.12? I ask this because, yes, this approach is very easy and works well for me on Windows as well. But the requirements.txt file specifies a Python version of 3.12 for nearly all the dependencies and I have to wonder if any of the Python code in the entire package actually has a hard dependency on 3.12. So, I wonder if you did this with a Python release < 3.12. It seems at a minimum. you would have had to remove the python_version options and downgrade the versions in the requirements file.

I also wonder if you did this (running AO on a system with GLIBC 2.35). AO contains compiled C code (the aoimage library) which is linked with GLIBC on the 24.04 build machine, which is 2.38. I'm guessing that cloning the repo and running the Python still would not work even if getting past the Python version question because the so files were linked against 2.38.

Generating a Linux build compatible with Ubuntu 22.04 isn't as easy as I implied above. Several changes to the Actions scripts are needed to get a 22.04 environment. (The Linux build steps start an additional (24.04) Docker container to do the build, and I don't know why.) And Ubuntu 22.04 comes with Python 3.10. I don't know if AO can work with 3.10, and installing Python 3.12 on 22.04 is a bit of a pain.

It seems that the Linux build got pushed ahead into the Python 3.12 / GLIBC 2.38 world a little too quickly? Maybe @ProgrammingDinosaur has some thoughts.

[mmaechtel]

@karlrado I'm using Debian 12 and I used pyenv to set up version 3.12.9 locally in my autoortho4xplane directory, which I cloned from GitHub.

ldd aoimage/aoimage.so
        statically linked
❯ ldd lib/linux/*.so
lib/linux/libispc_texcomp.so:
        linux-vdso.so.1 (0x00007f70edec5000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f70eda00000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f70edda3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f70ed81e000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f70edcc3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f70edec7000)
lib/linux/lib_stb_dxt.so:
        linux-vdso.so.1 (0x00007fb53755c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb537344000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb53755e000)


❯ pyenv version
3.12.9 (set by /home/xxx/Work/Xplane/autoortho4xplane/.python-version)

Take a look at the e.g. pyenv tool. It's easy to set up a local version of pyenv for just a directory, so you don't have to change the system's Python version.

The system Python installed on Debian 12 is version 3.11.2.

Works great !

[karlrado]

@mmaechtel Thanks for the reply.

OK, I see you accomplished this with 3.12, which is good because everything is set up that way.

In case it isn't clear, I'm talking about the environment that needs to be set up on the GitHub Actions runners, and not on a user's machine. On the runner, we spin up an Ubuntu instance with Docker, which is currently 24.04. If we change this to 22.04, we'd have to run additional configuration to install 3.12 in this 22.04 image. It isn't clear to me right now if pyenv would be easier than following the documented steps for installing a non-default version on Linux. Both require the Python build dependencies to be installed. But it seems this could be done without pyenv which would be better since one less component would be involved. Don't know yet.

---

Regarding GLIBC, I see that aoimage.so is statically linked, so no issue there. But the two other libraries were built on 24.04, which is GLIBC 2.38. Yet you are running on a machine with GLIBC 2.35. So I wonder how this worked. Maybe those two other libraries are not even used.

[karlrado]

@mmaechtel Thanks for the tip about pyenv! I ended up using it. I made a pull request that modifies the build system to build AO on both ubuntu-latest and ubuntu-22.04.

If anyone wants to test it out before the PR is accepted, that would be useful. Look for it here on my fork. Use the 1.4.2-rc-6 release, but please disregard the RC number, as they are relative to my fork and not this release stream.

[mmaechtel]

@karlrado I checked the source code (rc6) and it runs perfectly in my Pyenv environment. I then tested the Jammy build, which also runs perfectly in Debian 12.

[karlrado]

I checked the source code (rc6) and it runs perfectly in my Pyenv environment. I then tested the Jammy build, which also runs perfectly in Debian 12.

Thank you! I didn't have a Jammy (22.04) install anywhere, but I tried the Jammy binary on a WSL instance of 22.04 and it worked fine. So I think we're good and the PR (#181) should be good to go.

[sfrsfrsfr]

Thank you! i just tested (only briefly though) karlrados fork 1.4.2-rc-6 and it worked without issue. Looking forward to an official release with this PR merged.

[ProgrammingDinosaur]

This problem should be fixed with 1.5.0 (still in WIP). Nuitka is not used anymore