libc.so.6: version `GLIBC_2.32' not found

[bodsch]

I am currently revising my ansible roles for algernon and creating various tests with different operating systems.
In the process I noticed that algernon as of 1.12.11 does not work with CentOS 8, OracleLinux 8, debain9/10, ubuntu 20.04.

Here I get the following error:

# /usr/local/bin/algernon --help
/usr/local/bin/algernon: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /usr/local/bin/algernon)

• CentOS and OracleLinux ship with a glibc 2.28:

# rpm -qa | grep glibc
glibc-2.28-127.el8.x86_64

With Debian it looks similar:

• debian9:

# dpkg -l | grep libc6
ii libc6:amd64 2.24-11+deb9u4

• ubuntu 20.04

# dpkg -l | grep libc6
ii libc6:amd64 2.31-0ubuntu9.1

Up to version 1.12.8 all versions worked fine.

Were there such profound changes that a glibc > 2.31 is needed?

[bodsch]

Since version 2.12.11 there is an additional package with static (?) dependencies.
When I use this, my Ansible role works again.

I just hope now that the filenames stay stable! :)

[xyproto]

Hi, thanks for reporting.

Is this when building with go build -mod=vendor, or without using the vendored dependencies? Or is this for the release binaries?

[bodsch]

i has tested the release binaries.

[xyproto]

Thanks for the reply. I'll see if I can make a new release with CGO disabled, then I'll test it on Debian.

[xyproto]

Could you please try one of the _nocgo releases I added to the release page?

I also tested the original release files on Debian 10, but could not reproduce the problem.

[bodsch]

Thanks for the reply. I'll see if I can make a new release with CGO disabled, then I'll test it on Debian.

I use the static version for all versions above .10.
It works fine in my test environment and in the CI tests.

[bodsch]

Could you please try one of the _nocgo releases I added to the release page?

I also tested the original release files on Debian 10, but could not reproduce the problem.

What's the different beween
algernon-1.12.12-linux_nocgo.tar.xz and algernon-1.12.12-linux_static.tar.xz?

[xyproto]

Ah yes, algernon-1.12.12-linux_static.tar.xz is also compiled without CGO. The newest one is compiled with Go 1.16, though.

What are the steps to reproduce the issue? Can it be reproduced on Debian 10?

[bodsch]

Ah yes, algernon-1.12.12-linux_static.tar.xz is also compiled without CGO. The newest one is compiled with Go 1.16, though.

What are the steps to reproduce the issue? Can it be reproduced on Debian 10?

Of course.
I can create a new test branch of my ansible role in which I revert my fixes (to use the static build).
It will run on other operating systems like centos.

[xyproto]

Do you happen to know if this is still an issue?

If it is, how can I see it for myself?

[bodsch]

Sorry for the interruption.
I'll create a test branch for you to see.

https://github.com/bodsch/ansible-algernon/actions/runs/678533008

(I should document the call of the tests)
To run the test locally you need an installed molecule and tox (pip install molecule tox)
Then you can run the test via ALGERNON_VERSION=1.12.12 tox -e py39-ansible210 -- molecule converge start.
After end replace the converge with destroy: ALGERNON_VERSION=1.12.12 tox -e py39-ansible210 -- molecule destroy

I have integrated an extra task which prints the installed version.
In the github task the versions 1.12.8 and 1.12.12 are deployed to independent Docker containers.

[xyproto]

Thanks for adding the test. I updated the dependencies of Algernon.

Could you please re-trigger the Ansible test with the latest main branch of Algernon?

[xyproto]

Is this still an issue?

I'm considering building all future releases with CGO_ENABLED=0, and possibly also as static executables, if that may help.

[bodsch]

Sorry for the delay.
I'll look at the latest version as soon as possible.

[xyproto]

Great, thanks for testing. 🙂

[bodsch]

My Ansible role does not build artifacts, but uses releases exclusively.
Is there any way to generate a daily snapshot that I can pick up?

[xyproto]

The three methods I currently use for deployment are: installing directly with go, using the releases or using Docker.

I have a great impression of Ansible, but haven't really used it much.

What is the main problem that should be solved?

If I set up a server where you can visit an URL to download the latest main branch as an exectable, would that help?

For instance https://algernon.roboticoverlords.org/build?GOOS=linux&CGO_ENABLE=0 (does not exist yet) which would then build and serve the executable on the fly (and cache it as needed)?

[bodsch]

The three methods I currently use for deployment are: installing directly with go, using the releases or using Docker.

I have a great impression of Ansible, but haven't really used it much.

What is the main problem that should be solved?

While writing my Ansible role I noticed the problem what you described in the beginning.
Since this error seemed strange to me, I created a workaround and this issue.

Currently I can live with my workaround, Algernon runs on the supported target systems.

If I set up a server where you can visit an URL to download the latest main branch as an exectable, would that help?

For instance https://algernon.roboticoverlords.org/build?GOOS=linux&CGO_ENABLE=0 (does not exist yet) which would then build and serve the executable on the fly (and cache it as needed)?

That way I could at least test the current latest hot shit. :)
But if I'm the only one who would use this, then it's not worth the effort.
Thanks for the offer!

Bottom line: if you think this issue is pointless, I won't be mad if you close it!

Regards, Bodo

[bodsch]

Since my "workaround" works in my Ansible role, I would want to close the issue.

[xyproto]

Great. Thanks for caring about Algernon and filing an issue in the first place, though!