Error: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /root/workspace/backend/node_modules/uWebSockets.js/uws_linux_x64_72.node)
Latest glibc version for CentOS 7 is 2.17.
I know that latest version for CentOS 8 is 2.30 but I can't upgrade, because my VDS depends on host's machine kernel (which is very old).
Is there any way to run/compile it with glibc-2.17 or update glibc?
EDIT:
My kernel version is 2.6.32-042stab141.3.
I can build it and install to /opt/glibc-2.18 without errors, but when I trying to use this I see Segmentation fault error.
P.S. I builded it successfully on Fedora 23 with same OpenVZ kernel.
I have built a custom binary (and tutorial) that will solve your exact problem.
Read it here: https://github.com/dominicklee/uWebSockets.js-for-Centos7
Is there any way to run/compile it with glibc-2.17
Yes: just do it (download source, build on your target machine, profit).
or update glibc?
You didn't say what your "very old kernel" is, but if GLIBC-2.18 supports it, then yes, you can update GLIBC.
However, any mistake you make in the process may make your system un-bootable. See this answer.
Related
I have Fedora 31 installed which has gcc 9.3.1 installed into it.
I want to install gcc 4.8.5 on my machine.
Tried compiling the gcc by downloading tar file from gnu website, but facing lot of compilation errors.
Can anone help me with the installation.
Thanks in advance.
The compiler you are looking for was in a Fedora release many many years ago and will be hard to reasonably get going on a current Fedora Linux system.
However, it is the compiler in RHEL 7, and therefore in CentOS. Your best bet is to install one of those operating systems in a virtual machine. (You can get RHEL for individual use through the RH Developer Program.) In Fedora Workstation, the Boxes program makes it easy to set up such a VM.
You could also use a docker or podman container, but that will take a little more understanding.
How to run Deno on Webfaction's CentOS 7 (64-bit)?
It gives an error:
deno: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by deno)
Current Deno release 1.0.0 (latest today) is not compatible with CentOS 7.
I tried on the latest distribution released on 27 April 2020:
$ cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)
This issue 7 GLIBC_2.18 not found suggests that there should be a way to solve this problem, but the thread seems to be abandoned for a year.
As of today Deno requires GLIBC_2.18, but unfortunately CentOS 7 is running 2.17, an old version of the gclib which is not enough:
$ ldd --version
ldd (GNU libc) 2.17
If you need to run Deno on CentOS you'll need to use CentOS 8. Tested it and it works.
From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”:
That means the program was compiled against glibc version 2.14, and it
requires that version to run, but your system has an older version
installed. You'll need to either recompile the program against the
version of glibc that's on your system, or install a newer version of
glibc (the "libc6" package in Debian).
It will not happen for CentOS 7. From glibc_2.18 on Centos 7:
No. Never going to happen. We ship glibc 2.17 as part of CentOS 7 and
that will never change. It's part of the basic RHEL standards that
stuff like this does not change within a major version.
I wouldn't count on Deno — which is a new technology — to backport with old compilers. Consider upgrading your servers to CentOS 8.
For me, I have no way to upgrade the OS as it's managed by IT department. Seems there's a workaround. I found the link on the following thread does work.
https://github.com/denoland/deno/issues/1658#issuecomment-632986792
I am trying to build open embedded project. But it shows some error like
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: GLIBCXX_3.4.26 not found
How can i install GLIBCXX_3.4.26 in Ubuntu 16.04 ?
I believe the object you are trying to use was compiled with a fairly recent version of GCC 9 with this bug fixed. This GCC version has not yet been released.
You need to recompile it with the Ubuntu system compiler, or ask the Ubuntu compiler people to backport this fix into the Ubuntu 16.04 system compiler (which seems fairly unlikely to happen at this point).
I solved the problem by 2 steps:
1 Install a Anaconda3
2 Copy the file libstdc++.so.6.0.26 to path '/usr/lib/x86_64-linux-gnu', then create a soft link.
I worte the detail commands here.
This question already has answers here:
Deploying Yesod to Heroku, can't build statically
(4 answers)
Closed 6 years ago.
I am getting this error while I am running the code in GLIBC version 2.12, which was compiled in 2.19.What is the standard solution to this problem, so that the code can run in all versions.Upgrading the target machine to 2.19 is not an option because this software is supposed to run in at least 5000 machines.Dow grading the development machine to 2.12 is also not a proper solution. Because 2.19 is just one example. The 5000 target machines can have any version.What is the standard solution for this ? Anyway of static compilation ? I mean bundling the entire GLIBC with the code .
The easiest solution is to simply create a "build server" which you use for your production builds, and keep this server on the oldest version of everything you need to support, including glibc.
This can be done using a VM inside your development server if you don't want to use a physical machine.
Bbinaries compiled against glibc should be forward-compatible; the binaries you compiled against glibc 2.19 were using an API version that appeared in 2.14. If instead you compile against 2.12 it should work at runtime with Glibc 2.19 as well.
In Python-land, they're now offering prebuilt Linux C extensions that are built on Centos 5.11 Docker images; The PEP 0513 explains details. They seems to work pretty well there. Centos 5.11 seems to have glibc 2.5; Centos 6 has glibc 2.12. I am using these prebuilt .sos on Ubuntu 14.04 and 15.10 myself without any problems.
There is also a very hackish solution, by placing the required libc.so (2.19) file in a specific directory (just copy it over), creating a runner script, where you set the LD_LIBRARY_PATH to have the specific directory and then you run the executable. The system should pick up the libc.so from the specific directory before the one provided by the system, so it should work.
I am trying to deploy my application from development environment to users' computer, but I have some issues.
First, I compile and run it on my development computer (higher version Ubuntu11.04):
Ubuntu11.04$ make
Ubuntu11.04$ ./MyApp
Program runs okay.
Then I copied the binaries MyApp to two lower-version machines (users' computer):
Ubuntu10.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
Ubuntu8.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./MyApp)
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
However, if I compile the source code on Ubuntu10.04, and run it:
Ubuntu10.04$ make
Ubuntu10.04$ ./MyApp
Program runs okay.
What should I do with this? When I compile it in development environment, how can I set the version number of the used library? I'm not directly using GLIBCXX, I think it's being used implicitly somewhere in my project.
Thx a million.
Peter
Did you see Link with an older version of libstdc++
I have never installed an older version of g++, but I have included a libstdc++.so in my release and that has worked for me. Best solution I have seen is get your development stuff to work on the oldest possible system. We compile some stuff on Red Hat 9 and it work on everything, but it can be any major issue building on old machines as you say.
You have built on version N, and tried to deploy on version M, M<N. You will need to get the deployment computer upgraded, or learn the procedure to compile and link targeting an older version. Since the problem lives in libstdc++, I'm afraid that my advice is to downgrade your entire dev system or upgrade the target, libstdc++ is not easy to deal with. Another answer here has someone's recipe.
Keep in mind that the Ubuntu/Debian community is optimized for open source. From their point of view, the solution to this is for you to distribute source code with the auto* tools, and let the user built it for him or her-self. They don't stay up late making this easy for you.
Here in the evil world of closed source, we keep around VMs running all sorts of old linux distros just so that we can build a single binary that runs in many places.