Issue: Could you please package the GPT4All using a lower version of GLIBCXX?

[Dee-Ma]

Issue you'd like to raise.

Hi @cosmic-snow,

Many thanks for releasing GPT4All for CPU use! We have packaged a docker image which uses GPT4All and docker image is using Amazon Linux. In the packaged docker image, we tried to import gpt4all but it returned an error message: OSError: /lib64/libstdc++.so.6: version GLIBCXX_3.4.26' not found (required by /home/app/gpt4all/llmodel_DO_NOT_MODIFY/build/libllmodel.so)`.

Then, we used a command strings /lib64/libstdc++so.6 | grep GLIBCXX to check which versions of GLIBCXX that we have in the docker image and it shows below output: GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBCXX_3.4.21 GLIBCXX_3.4.22 GLIBCXX_3.4.23 GLIBCXX_3.4.24 GLIBCXX_DEBUG_MESSAGE_LENGTH

Indeed, the 'GLIBCXX_3.4.26' has not been included in the docker image.

Suggestion:

We are wondering that could you please release/package the GPT4All using a lower version of GLIBCXX (e.g., GLIBCXX_3.4.24) which can support using Amazon Linux? If the lower version of GLIBCXX can be supported, it would be really helpful. Or, could we modify any file to reduce the version requirement of libllmodel.so in GPT4All?

Thanks!

[cosmic-snow]

Hi. Not sure why you're pinging me, specifically.

A few things of note/comments to your specific situation:

• I'm not doing any of the packaging.
• The PyPI version is built on an Ubuntu 22.04 , hence the GLIBC and GLIBCXX minimum requirements are what's available there.
• The API however is targeting a Python Docker image, which is based on a Debian version (I think bookworm), as far as I know.
• If you're already using Docker, why can't you target a base image that has a more modern stack? Having that flexibility is one of the strengths of running things in a container, imho.
• If that's not possible, it should still be pretty easy to just compile a version yourself and use that in a base/intermediate layer of your image. It mostly just requires building the backend, which should be relatively easy to do (for now, at least).

That said, I don't want this to read as for or against implementing this.

[odarcan]

I have similar issue version `GLIBC_2.34' not found (required by ./chat) people in linux support irc dont even bother to help, asking me what kind of obscure thing Im trying to install Im not an advanced user in linux, so this is probably affecting a lot of people. Unless using some feature that dont exist in earlier version of glibc perhaps it is better to make it use a older version.

I use mint, when updating with apt, I get glibc-source is already the newest version (2.31-0ubuntu9.9).

[cosmic-snow]

I have similar issue version `GLIBC_2.34' not found (required by ./chat) people in linux support irc dont even bother to help, asking me what kind of obscure thing Im trying to install Im not an advanced user in linux, so this is probably affecting a lot of people. Unless using some feature that dont exist in earlier version of glibc perhaps it is better to make it use a older version.

I use mint, when updating with apt, I get glibc-source is already the newest version (2.31-0ubuntu9.9).

I guess you're using an older version of Linux Mint then? Current variants build on Ubuntu 22.04.

The system that produces the releases is on Ubuntu 22.04 LTS, and as such some base libraries are linked against the versions that are available in that.

If you look through the issues, some people did try to build on Ubuntu 20.04 or other systems that have older glibc libraries. Some were successful, but one problem with Ubuntu 20.04 is that it's using an old version of the SSL library, if I remember that right.

For now, you should either update your distro or try building it yourself. (There's also a Flatpak version, but I don't know the current state of that. Edit: coming soon.)

[odarcan]

upgrading mint worked, thanks!

[marklit]

Ubuntu for Windows uses Ubuntu 20.04 which only supports glibc up to 3.4.28 with its packaging system. sudo apt-get upgrade libstdc++6 won't push that version up any further.

llm = GPT4All(
    model="./ggml-gpt4all-j-v1.3-groovy.bin",
    n_ctx=1000,
    backend="gptj",
    verbose=False
)

OSError: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /home/mark/.lc/lib/python3.8/site-packages/gpt4all/llmodel_DO_NOT_MODIFY/build/libllmodel.so)

When I ran the above it looked like there was only libllmodel.so that calls out to throw_bad_array_new_lengthv in 3.4.29. If this one call wasn't there this .so would work on Ubuntu for Windows out of the box without issue most likely, at least for anything using this .so file.

$ strings /home/mark/.lc/lib/python3.8/site-packages/gpt4all/llmodel_DO_NOT_MODIFY/build/libllmodel.so | grep -o '@GLIBCXX.*' | sort | uniq -c

     31 @GLIBCXX_3.4
      1 @GLIBCXX_3.4.14
      2 @GLIBCXX_3.4.18
      1 @GLIBCXX_3.4.20
      7 @GLIBCXX_3.4.21
      8 @GLIBCXX_3.4.26
      1 @GLIBCXX_3.4.29
      2 @GLIBCXX_3.4.9

$ strings /home/mark/.lc/lib/python3.8/site-packages/gpt4all/llmodel_DO_NOT_MODIFY/build/libllmodel.so | grep '@GLIBCXX_3.4.29'

_ZSt28__throw_bad_array_new_lengthv@GLIBCXX_3.4.29

[EchedelleLR]

an old version of the SSL library

Which is in fact supported as LTS by the OpenSSL team.

[jhgoebbert]

Pre-built packages on PyPI are IMHO usually built with glibc 2.17, as glibc guarantees upward compatibility to newer versions. It might be a more compatible solution to build the packages on a Linux distributions based on RedHat 7 as these are using glibc 2.17. To help users choosing the right package the glibc version is in general part of the file name, e.g. here the 2_17 if gpt4all would be build on a RedHat 7: gpt4all-2.2.1.post1-py3-none-manylinux_2_17_x86_64.whl

[cebtenzzre]

Pre-built packages on PyPI are IMHO usually built with glibc 2.17

Yeah, there is a whole way you are supposed to do things with a C extension build and cibuildwheel.

Meanwhile, we are just sneaking things in via package_data= and then using the deprecated python setup.py bdist_wheel --plat-name=whatever. The result of this is that on at least Linux and macOS, you can pip install something that won't run on your platform, which really shouldn't be possible.