Skip to content

Precompiled mdbook gnu executable requires newer glibc version (v0.4.23) #1954

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jontze opened this issue Dec 15, 2022 · 1 comment · Fixed by #1955
Closed

Precompiled mdbook gnu executable requires newer glibc version (v0.4.23) #1954

jontze opened this issue Dec 15, 2022 · 1 comment · Fixed by #1955

Comments

@jontze
Copy link

jontze commented Dec 15, 2022

With the latest v0.4.23 release the precompiled mdbook-v0.4.23-x86_64-unknown-linux-gnu.tar.gz binary doesn't run on the github runner of ubuntu-20.04 anymore. As it fails with the following error:

mdbook --version
mdbook: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by mdbook)

Further workflow logs her: https://github.com/jontze/action-mdbook/actions/runs/3702275493/jobs/6272375311. It still works on the latest ubuntu-22.04 runner.

I observed this behavior especially in context of the current ongoing github ubuntu-latest runner rollout: actions/runner-images#6399 . So ubuntu-latest will slowly switch from 20.04 to 22.04.

With the latest mdBook release, the build of the precompiled binaries are now executed on ubuntu-22.04.

Other projects where affected by this as well and their selected solution was to build the precompiled binaries on ubuntu-20.04 instead of ubuntu-latest.

- target: x86_64-unknown-linux-gnu
os: ubuntu-latest

For example the nushell project had the same issue:

So we might choose this way as well for the mdBook builds. However, I'm not quite sure if this is the way to go, or if there are better solutions to resolve this.

@ehuss
Copy link
Contributor

ehuss commented Dec 15, 2022

Thanks for the heads up! I posted #1955 to fix it. In the mean time, I might suggest using the musl binary which is currently statically linked and shouldn't exhibit the same problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants