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
Related
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.
I want to build a inux-based program fully standalone for windows.
And I try to use mingw64 on ubuntu with the command
./configure --host=x86_64-w64-mingw32 --disable-shared --enable-static LDFLAGS="-L /usr/local/lib/"
make
But it failed with
src/libcork/posix/subprocess.c:14:24: fatal error: sys/select.h: No such file or directory
#include <sys/select.h>
^
compilation terminated.
Here is the source code in github:
https://github.com/shadowsocks/simple-obfs
So how can I build the program fully standalone for windows?
May I try the cygwin or msys2?
update:
I find another source code which has been ported.
But when I compiled it with
./configure --host=x86_64-w64-mingw32 CFLAGS="-static" LDFLAGS="-static"
I get an executable file which still needs the libssp-0.dll.
So how can I make the libssp be static linked?
Here is the new source code: https://github.com/Windendless/simple-obfs
I don't think that the functionality in select.h is available on the MinGW version of gcc, because it is not available in the Windows platform. If you're building something that was intended to be built on Windows, then you might find that there are options you can pass to configure that enable a different, Windows-friendly way of achieving the same thing. If you're building something that was only really intended to be used on Linux, then you might be out of luck. In that case, your choices really amount to:
Modify the code so it doesn't require select.h. Some of that functionality might already exist in the Windows Sockets API, with a somewhat different implementation. However, it might equally well not, in which case you'll have to do some work.
Use a Windows compatibility layer that is more feature-rich than MinGW. Cygwin might well work, as might the Windows Subsystem for Linux in Windows 10. However, none of these approaches amounts to building a "standalone" application, because they require some supporting infrastructure.
I have a problem connected to a version of the openmpi library. Recently I had installed the newest stable version of the openmpi (1.10.2) and one of the programs I use stopped working. There is an error message when I run it:
error while loading shared libraries: libmpi.so.1: cannot open shared object file: No such file or directory
Indeed, there is no such a file in my system. There is however a newer version of the library - libmpi.so.12 and libmpi.so.12.0.2. Other programs, which are using openmpi, work without any error, which proves that the library was installed correctly (at least I think so (: ).
Unfortunately, I don't know which version of the openmpi was used to compile the program. I don't have access to its source code, so I cannot compile it against the newer library. I noticed that I can make the program run if I copy the libmpi.so.12 to the file called libmpi.so.1
Therefore, I have two questions:
Is it reasonable to use the workaround I've found? I have some doubts, although the program appears to run well.
Is there a way to check which version of the openmpi library was used during a compilation?
Thanks in advance.
EDIT:
I use Linux Mint 17.3.
I have a Qt application that I am trying to run, but fails to start because it "could not find or load the Qt platform plugin "xcb". When I run ldd on libqxcb.so all the libraries are linked except for one: libxcb-icccm.so.1 => not found
Now, I do have libxcb-icccm.so.4 on my machine, but if I create a symlink pointing to it, everything crashes and burns. From everything I've found the icccm library comes from the XOrg libs, but when I download the source to build it, I have thus far ended up with libxcb-icccm.so.4 instead of libxcb-icccm.so.1
Am I doing something wrong, or am I just missing the version of the xcb libraries I need to build libxcb-icccm.so.1
This version of the icccm library can be found in: xcb-util-0.3.6
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.