Skip to content
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

Compatibility issue for version 0.19.8 GLIBC_2.29' not found #596

Closed
don-chau opened this issue May 5, 2022 · 30 comments
Closed

Compatibility issue for version 0.19.8 GLIBC_2.29' not found #596

don-chau opened this issue May 5, 2022 · 30 comments

Comments

@don-chau
Copy link

don-chau commented May 5, 2022

There is unstated compatibility issue for new 0.19.8 version

Error: /lib64/libm.so.6: version GLIBC_2.29' not found`

The new version require GLIBC_2.29 which better state in changelog or improve for backward compatiability?

@tuananh
Copy link
Contributor

tuananh commented May 6, 2022

@don-chau what's the OS and arch you're using?

@tuananh
Copy link
Contributor

tuananh commented May 6, 2022

@rchipka looks like libxmljs needs to static link when building binaries?

but it has always been shared_library? I did not make any change related to that in the recent PR.

maybe it's because of the newer OS used when building?

@don-chau
Copy link
Author

don-chau commented May 6, 2022

I know I am having a rather old system...
It work fine with 1.19.7

Centos 7
node version: v14.17.6
npm version: 6.14.15

` $ /lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.8.5 20150623 (Red Hat 4.8.5-44).
Compiled on a Linux 3.10.0 system on 2021-10-13.

`

@chanyk-joseph
Copy link

chanyk-joseph commented May 6, 2022

Hi @tuananh
The same issue happens on Ubuntu 18.04.6 LTS (with glibc 2.27)
node v14.17.0
npm v8.5.2

No glibc not found exception using libxmljs v0.19.7

@tuananh
Copy link
Contributor

tuananh commented May 6, 2022

my guess would be because I'm using ubuntu-latest (which is ubuntu 20.04) in my recent pr to build binaries.

maybe I should switch to lower version to build to match with older releases? or should I change to static_library in binding.gyp? wdyt @rchipka

https://github.com/actions/virtual-environments#available-environments

@lachesis
Copy link

lachesis commented May 6, 2022

This has broken our systems in production. We did not upgrade anything, but we did an "npm install" which apparently downloaded the new broken build. Ubuntu 18.04 is still supported for another year. Please revert to building on 18.04 or build statically.

@rchipka
Copy link
Member

rchipka commented May 6, 2022

It's been "shared_library" for 8 years now, so I'm hesitant to change it, but I think that's the correct answer here if we want to avoid C library version incompatibility.

@rchipka
Copy link
Member

rchipka commented May 6, 2022

Give v0.19.9 a try

@don-chau
Copy link
Author

don-chau commented May 6, 2022

Tested with v0.19.9 on Centos 7

/node_modules/libxmljs/build/Release/xmljs.node: invalid ELF header\n at Object.Module._extensions..node (internal/modules/cjs/loader.js:1131:18)\n at Module.load (internal/modules/cjs/loader.js:937:32)\n at Function.Module._load (internal/modules/cjs/loader.js:778:12)\n at Module.require (internal/modules/cjs/loader.js:961:19)\n at require (internal/modules/cjs/helpers.js:92:18)\n at bindings (/<...>/node_modules/bindings/bindings.js:84:48)\n at Object.<anonymous> (/<...>/node_modules/libxmljs/lib/bindings.js:1:37)\n at Module._compile (internal/modules/cjs/loader.js:1072:14)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)\n at Module.load (internal/modules/cjs/loader.js:937:32)\n at Function.Module._load (internal/modules/cjs/loader.js:778:12)\n at Module.require (internal/modules/cjs/loader.js:961:19)\n at require (internal/modules/cjs/helpers.js:92:18)\n at Object.<anonymous> (/<...>/node_modules/libxmljs/index.js:4:16)\n at Module._compile (internal/modules/cjs/loader.js:1072:14)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)"

@tuananh
Copy link
Contributor

tuananh commented May 7, 2022

i got issue with latest release as well

Error: /home/anh/Code/test/node_modules/libxmljs/build/Release/xmljs.node: invalid ELF header
    at Module._extensions..node (node:internal/modules/cjs/loader:1189:18)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Module._load (node:internal/modules/cjs/loader:827:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at bindings (/home/anh/Code/test/node_modules/bindings/bindings.js:84:48)
    at Object.<anonymous> (/home/anh/Code/test/node_modules/libxmljs/lib/bindings.js:1:37)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32) {
  code: 'ERR_DLOPEN_FAILED'
}

Node.js v18.1.0

@peeweep
Copy link

peeweep commented May 7, 2022

same issues here.

peeweep@gentoo /tmp % cat test.js 
var libxmljs = require("libxmljs");

@lachesis
Copy link

lachesis commented May 7, 2022

We upgraded our servers to 20.04 in order to escape this issue. It seemed like a more sure-fire way to resolve it than waiting for this repo to be corrected or trying to find the right magic invocation to get an old version of node & libxmljs working. Random question... what is the second version number in the github release? e.g. v82

@tuananh
Copy link
Contributor

tuananh commented May 8, 2022

We upgraded our servers to 20.04 in order to escape this issue. It seemed like a more sure-fire way to resolve it than waiting for this repo to be corrected or trying to find the right magic invocation to get an old version of node & libxmljs working. Random question... what is the second version number in the github release? e.g. v82

"package_name": "{node_abi}-{platform}-{arch}.tar.gz"

it's node application binary interface (ABI) version

@damellis
Copy link

damellis commented May 9, 2022

With libxmljs 0.19.8, I was able to resolve the GLIBC issue (on CentOS 7, w/ GLIBC 2.17, node v12.22.12, npm 8.9.0) by running: npm install --build-from-source libxmljs before npm install. It would be nice if npm / node-pre-gyp would fall back to building from source on systems with an older, incompatible GLIBC, but it seems that it doesn't.

Now I'm hitting the invalid ELF header error with libxmljs 0.19.9 (still using npm install --build-from-source libxmljs). Maybe node is statically linked against different libraries than those used to build libxmljs? Or something is changing on my system between building libxmljs and running my node application?

@rchipka any chance of going back to a shared library build? That seems like it would make it easier to get things working again for systems with older GLIBC versions by building from source. It might also reduce the risk of incompatibilities for the pre-built binaries, even for systems with compatible versions of GLIBC.

Alternatively, anyone know of a way to force npm / node-gyp to build a shared library (overriding the configuration in binding.gyp)? Or have any other suggestions?

@lachesis
Copy link

lachesis commented May 10, 2022

Huh now I'm getting invalid ELF header as well. Second outage in three days thanks to this library. 😞 Fortunately downgrading to 0.19.8 fixed the issue for me (on Ubuntu 20.04).

@rchipka
Copy link
Member

rchipka commented May 10, 2022

Reverting back to shared_library

@rchipka
Copy link
Member

rchipka commented May 10, 2022

If we build releases on ubuntu-18.04, does anyone know if that will break things for ubuntu-latest? If it's one or the other I suppose it'd be best to keep it as the latest version.

Also, --fallback-to-build is set, but that's only if a pre-compiled binary isn't found, not when the pre-compiled binary doesn't work.

@nivlheim
Copy link

How about ubuntu 16.04? It's still supported until 2026 through ESM.

@akashepik
Copy link

Facing the same issue with the latest version of this package, using an older version of the package helps as a workaround,
0.19.7 fits the case.

@nivlheim
Copy link

nivlheim commented May 12, 2022

using an older version of the package helps as a workaround, 0.19.7 fits the case.

@akashepik 0.19.7 has some vulnerabilities - instead try building the newest version from the source (--build-from-source)

@lachesis
Copy link

I would expect that if you build on an older version of Ubuntu, then newer versions will work as well. I dealt with the same issue on the Dropbox desktop client back in 2016. At the time, we ended up using Ubuntu 12.04 as our minimum version and it worked all the way up to at least 16.10. Not sure if they ended up rolling forward to 18.04 later.

pirtleshell added a commit to hackoregon/openelections that referenced this issue May 16, 2022
has problem with latest build.
see libxmljs/libxmljs#596
pirtleshell added a commit to hackoregon/openelections that referenced this issue May 21, 2022
has problem with latest build.
see libxmljs/libxmljs#596
@rchancey
Copy link

Can you guys make a new version that fixes the Error: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /opt/atlassian/pipelines/agent/build/node_modules/libxmljs/build/Release/xmljs.node) issue?

@bugre
Copy link

bugre commented Oct 19, 2022

Hi,
To add on the systems having issues.. we run loads on AWS with "Amazon Linux AMI 2018.03" / glibc 2.17 (i know it's old but still under maintenance support until mid next year) we also get the error:

Error: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /dsv/node_modules/libxmljs/build/Release/xmljs.node)

looking for alternatives as the build-from-source and other options aren't viable in our workflow.

@tuananh
Copy link
Contributor

tuananh commented Oct 20, 2022

Hi, To add on the systems having issues.. we run loads on AWS with "Amazon Linux AMI 2018.03" / glibc 2.17 (i know it's old but still under maintenance support until mid next year) we also get the error:

Error: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /dsv/node_modules/libxmljs/build/Release/xmljs.node)

looking for alternatives as the build-from-source and other options aren't viable in our workflow.

if i were you, i probably would fork this lib and use an instance with Amazon Linux AMI 2018.03 for building binary. it's probably not a lot of work as this version is freezed at the moment, waiting for 1.0 rewrite release. #585

the reason for this is probably we're using ubuntu-latest in the current release. maybe downgrading to an older version of ubuntu (that use older glibc) would help

os: [ ubuntu-latest, macos-latest, windows-2019 ]

@fadelardi
Copy link

The official Node docker "slim" image for Gallium (https://hub.docker.com/layers/library/node/gallium-slim/images/sha256-1d5b38c2dc2a7752a13818dfef9c0ad752cbc3becee097053fac460a57120a8b?context=explore) has GLIBC 2.28, making it incompatible out of the box unless additional steps are taken.

@tuananh
Copy link
Contributor

tuananh commented Nov 3, 2022

The official Node docker "slim" image for Gallium (https://hub.docker.com/layers/library/node/gallium-slim/images/sha256-1d5b38c2dc2a7752a13818dfef9c0ad752cbc3becee097053fac460a57120a8b?context=explore) has GLIBC 2.28, making it incompatible out of the box unless additional steps are taken.

Thats a valid reason

@rchipka rchipka closed this as completed Mar 29, 2023
@olastor
Copy link

olastor commented Apr 4, 2023

@rchipka Why has this been closed? It still does not work for me with the latest version v1.0.7 and the "node:16" or "node:18" image.

@rchipka rchipka reopened this Apr 4, 2023
@rchipka
Copy link
Member

rchipka commented Apr 4, 2023

We now build on really old linux systems with either glibc 2.14 or glibc 2.28, so this should be fixed in v1.0.8

Can someone here verify?

@olastor
Copy link

olastor commented Apr 5, 2023

We now build on really old linux systems with either glibc 2.14 or glibc 2.28, so this should be fixed in v1.0.8

Can someone here verify?

@rchipka It does seem to work for me now with v1.0.8 and both the node:16 and node:18 docker image 🎉 Thanks for addressing this so quickly!

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

No branches or pull requests