When I try to run an application that uses node-webcrypto-ossl node module I get the error:
Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found.
Obviously node-webcrypto-ossl requires an older version of glibc.
The version of glibc installed on my machine is 2.33-5. I've tried downgrading my glibc but ended up with a broken system (fixed it already).
How do I resolve the issue?
Obviously node-webcrypto-ossl requires an older version of glibc.
No. GLIBC is backwards compatible: applications built against older version continue to run fine on newer GLIBC versions.
Your problem is the opposite: you have an application linked against GLIBC_2.32 trying to run against an older version of GLIBC.
The version of glibc installed on my machine is 2.33-5
The application is not using that version; it's using some other GLIBC.
The problem was that I was trying to run my app in docker ...
That's one way running against older than expected GLIBC could happen.
Related
I'm trying to cross-compile (from x86_64 linux to ARMv7a) for certain applications. The host was running Linux 4.4.0 and the target was running Linux 3.0.2
I was able to successfully build such application using cross-compile toolchain from Linaro
However, the problem occurred when I executed the binary
Fatal: kernel too old
After some researchs on the Internet, I discovered that workaround would be to also cross-compile glibc as well with --enable-kernel=VERSION option and another problem came with this option.
configure: WARNING: minimum kernel version reset to 3.2.0
Is there any workaround to set kernel version to the one older than 3.2.0?
Is there any workaround to set kernel version to the one older than 3.2.0?
No. Support for kernels below 3.2 was dropped in glibc-2.24, and you can't bring it back (short of reverting the commits that did it).
You will need to build glibc-2.23 or older.
I'm working with Node.js 8.9.4, the current LTS version.
If I download the 64 bit Linux binary distribution of that version from the Node.js website (https://nodejs.org/dist/v8.9.4/node-v8.9.4-linux-x64.tar.xz), then the node executable it includes will run on Red Hat Enterprise Linux 6. (I need to be able to target this version of RHEL).
I have also built Node v8.9.4 from source, following the instructions at https://github.com/nodejs/node/blob/master/BUILDING.md#building-nodejs-on-supported-platforms. Doing this required gcc 4.9.4 or newer, as per that page, because C++11 support is now required.
However, the node binary that results from that build will not run on RHEL 6, because the standard C++ library (libstdc++.so) that ships with RHEL 6 is from GCC 4.4.7. It's necessary to reference the libgcc and libstdc++ from the newer version of GCC that was used to build node to get it to work.
I think this means that the Linux binary distributions on the Node.js website are not built using the process described in the build instructions - if they were, they would not run on RHEL 6.
Is there any information on how the binary distributions of Node.js are built? Are there some options to the configure script that I'm missing?
(The reason for this question: I'm trying to build a Node C++ add-on, which needs to target RHEL 6, and hitting the same problem with the version of gcc required to build it vs. the version of the GCC/C++ runtime on RHEL 6. Yes, I could distribute the runtime libraries with my application, but there is obviously a better solution, because the binary distribution of Node is using it).
I am trying to develop an application for a Linux based custom device. My build environment(Ubuntu 16.04) uses GLIBC-2.23 and all of other applications use this version but new custom device uses an old version of GLIBC so I am getting
/lib/libc.so.6: version `GLIBC_2.16' not found (required by /opt/myapp/lib/libcurl.so.4)
I cannot change my build environment and I cannot update also custom device GLIBC.
So, got stuck.
Maybe I can link new glibc version just with my application explicity but I dont know how can I do that?
I tried following but stil same
/lib/ld-linux.so.3 --library-path /opt/myapp/lib/ <APP>
Any idea.
I cannot change my build environment
You sure can do that, in several different ways, such as:
Install a virtual machine configured to use older GLIBC, compile the app inside of the VM
Configure a chroot environment, with older GLIBC and toolchain
Build a linux-to-older GLIBC cross-compiler.
Maybe I can link new glibc version just with my application
That's possible, but more complicated. Details here.
A C program compiled here runs fine on our Ubuntu servers. But when a somebody else tries to run it on their particular Linux server they get the following errors:
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./myprog-install)
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.7' not found (required by ./myprog-install)
Do I need to upgrade our glibc libraries and recompile? Or are they missing something on their server?
If I run apt-cache show libc6 my Ubuntu tells me the version is:
Package: libc6
Priority: required
Section: libs
Installed-Size: 9368
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss#lists.ubuntu.com>
Original-Maintainer: GNU Libc Maintainers <debian-glibc#lists.debian.org>
Architecture: i386
Source: eglibc
Version: 2.11.1-0ubuntu7.10
If I look at http://packages.ubuntu.com/hardy/libc6 the current version appears to be 2.7-10ubuntu8.1.
I'm confused by the numbers. On the one hand 2.11-1-0 is a higher number than 2.7-11. On the other hand 7.10 is a lower number than 8.1.
Is it just a matter of me upgrading the C library package and recompiling do you think? Or is the other person's server missing some needed library there for compatibility?
You have built on glibc-2.11 system. You are trying to run on a system with glibc-2.3 or older. That's not going to work.
Is it just a matter of me upgrading the C library package
No: upgrading your glibc will only make things worse.
You may want to try solutions listed here.
Is this something we can reasonably request the other party to upgrade their system to support, rather than downgrade our compiler?
Usually the client will strongly resist requests to upgrade their system: it's working fine for them as is, and any upgrade can break other existing applications.
If you are planning to distribute binaries on Linux (as opposed to building them on the target system), then you need to learn how to make binaries that will run everywhere, or you need to state your requirements (minimum kernel and libc versions, etc.) and turn clients who can't meet these requirements away.
Update:
Why did they get two errors. Why didn't they just get one for GLIBC_2.11.1 which is apparently what I built with?
Symbol versioning doesn't work that way.
When a new symbol is introduced, it is marked with the current libc version, e.g. readdir64##GLIBC_2.2, posix_spawn##GLIBC_2.15, etc.
When you link a program that uses both of the above symbols, and try to run it on e.g. glibc-2.1 system, you would get two errors.
But if you link a program that doesn't use any of the above symbols, e.g.
int main() { return 0; }
then your program will just run without any errors.
Update 2:
they don't have to add both GLIBC_2.4 and GLIBC2.7 to their Linux system, do they?
No, they don't. The GLIBC_2.11 will have all the previous symbols in it. In fact, they couldn't install both glibc-2.4 and 2.7 even if they wanted to: it is quite difficult to have multiple versions installed at the same time, and impossible to have multiple versions installed in default location.
You've built it against a version of glibc that is too new. Build it against an older version of glibc, preferably the one that they are using.
you need to build on a system that uses same versions of libraries as you do. This is where docker and VM's are very convenient. There is probably a pre-made docker image for whatever version the customer has.
I'm attempting to build a binary package that can be run on multiple Linux distributions. It's currently built on Ubuntu 10.04, but it fails on Ubuntu 8.04 with the following error:
./test: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./test)
./test: /usr/lib/libstdc.so.6: version `GLIBC_2.11' not found (required by ./test)
What's the preferred way to solve this problem? Is there a way to install an old glibc on a new box and build against it, or do I have to build on an old distribution? And if I build against an old glibc, will it work on a new glibc?
Or, alternatively, are there just some handy compiler flags or packages I could install to solve the problem?
The best solution I've found is to install a virtual machine running Debian stable, and build on that. Debian stable is old enough that any packages built with it will run on any other Debian-based distribution like Ubuntu. You may have to work around non-critical bugs that have been fixed in later versions of various software but not backported to Debian stable.
If you really want to make sure it runs on every recent distribution, you might also consider statically linking against a libC you select. However you may then still run into problems if you use features that are only provided by newer kernels (newer system calls e.g.).