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.
Related
i trying to create a appimage for my Linux system. Using qt-creator i have completed the programing and ran the app successfully . but when i am trying to make it appimage using linuxdeployQt i am facing some errors
linuxdeployqt 5 (commit 37631e5), build 631 built on 2019-01-25 22:47:58 UTC ERROR:
The host system is too new.
Please run on a system with a glibc version no newer than what comes with the oldest still-
supported mainstream distribution, which currently is glibc 2.20.
This is so that the resulting bundle will work on most still-supported Linux distributions.
For more information, please see
https://github.com/probonopd/linuxdeployqt/issues/340
i don't know what this issue is. when i visit the website, it is not clear also. So anyone familiar with this kind please put your help here.
It means that your glibc is too new.
That's correct, to work around this issue while using linuxdeployqt you have to choose as build environment an older system such as Centos 6 or Ubuntu 14.04.
As an alternative, you can use appimage-builder which allows producing AppImages on newer systems.
It means that your glibc is too new. I think it is supported glibc version comes with Ubuntu 14.04 as it is mentioned in herr https://github.com/probonopd/linuxdeployqt/issues/340. I have faced the same problem and still struggling to solve this issue.
I'm trying to deploy my application as a stand-alone that can work on any Linux machine. I've built my application under Qt Creator and have successfully statically linked my application. However, when I test the application on another Linux machine, I get the following error:
libstdc++.so.6: version 'GLIBCXX_3.4.21' not found (required by ./Executable)
I'm not sure how to resolve this error.
This is a error i had myself, but in another context.
What this means is: libstdc++.so.6 (a shared object file, the standard library of c++ programms, that many programms can use together(share)) is another version then the program you compiled requires.
i had this issue when switching from gcc-4.8 to gcc-5.
Have you using different linux distros when compiling and executing? (Ubuntu?)
You must make sure the versions match, or statically compile the used libstdc++ into your binary as well.
Here is a SO question relating to these kind of issues.
GLIBCXX versions
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.).
Can I install an older version of gcc/g++ (4.1.3) on the latest Ubuntu (which comes with 4.4.3) and use it to compile a .so which should run on CentOS? The binary compiled with the Ubuntu version of gcc fails to load on CentOS because of missing imports (GLIB_2_11, ...). I need C++ (including exceptions), so I can't just statically link against glibc, which I already tried.
Can I install the older gcc without removing the newer one? How do I go about the libs required by the older gcc?
I'm currently developing code in CentOS, but it's such a pain to use. I really want to move to an Ubuntu desktop.
g++-4.1 is available for Ubuntu; just run apt-get install g++-4.1 then run g++-4.1 instead of g++. However, simply using an older compiler may not fix all of your library issues.
Like Joachim Sauer said, your best bet is to do your development on Ubuntu then do the final compilation on CentOS.
Even though you're using C++, static linking should still be an option. (However, you're much better off compiling on CentOS and using dynamic linking.)
Edit: A virtual machine is the most straightforward way to build on CentOS, but if you want to avoid the memory and CPU overhead of running a VM and don't care about differences between Ubuntu's and CentOS's kernel, then you can create a subdirectory containing a CentOS or Fedora filesystem and chroot do that to do your builds. This blog posting has details.