I have a problem, i'm compiling my C++ app in Linux machine. Then i move executable to other machine, but i have an error:
./server: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by ./server)
How can i fix it? Without recompiling on second machine where this error happens (it is my client machine)
Compile command:
g++ -o server test.cpp server.cpp ... -lboost_system -lboost_thread -std=c++0x
Thanks!
Your app is using glibc-2.7 library, and app can not find it on other machine. It probably have older version of this library. You have following options:
Upgrade this library on target host
Link you app against older library version
Use static linking
Ship library together with app
How statically link to just one library:
gcc main.c mylibrary.a -o main
Note that most distros do not install static libraries by default.
There are three choices:
compile on the original machine with -static given to the compiler, which will include the relevant libraries in your binary [and possibly give you a warning or two about "this may not work right"]
compile the code on the new machine.
Install the correct version of library on the target machine.
I tend to use option 1 most of the time, but have used all three at various points.
Related
I'm upgrading a project from gcc 4.3 to 12.1 (a major jump) on Centos 7 & 6 - both 64 bit. As part of that I'm having trouble with what I suspect is an indirect dependency on a very old version of libgmp.
The submodule I'm compiling does not require any external libraries, however while running make I get the error:
gcc_12.1.0_path/cc1plus: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory
Google search does not turn out anything useful, issues that turn up are different than my case, my ld_library_path vars, lib paths are set correctly. libgmp v 3 is not available on my machine, and ideally I do not wish to install it, instead figure out where the dependency is and try upgrade it to use a more recent version of libgmp.
Even more confusing is, libgmp3 is not supported by centos 7 (or gcc 12). I'm not sure what part of compilation is dependent on this library, or how that part was successfully compiling with gcc 4 on centos 6.
The command for compilation is
g++_path -g -Wno-deprecated -D_DEBUG -fPIC -m64 -DLIN64BIT -I multiple_include_paths -o object_path -c source_file no -L inclusions
I wish to know two things:
In this case, what information should I provide to seek help?
Is there any tool for 2nd level or further (indirect) dependency
analysis? Would a c++ package manager help with such cases?
Is it possible to use libgmp v 3 built on another platform and copied to my lib path to resolve this (I do not have immediate access to such a machine or lib hence cannot check immediately)
Are there any suspects based on just the message and command?
I trying to link statically the standard library libc++ (https://libcxx.llvm.org/) in Linux (Arch using this AUR https://aur.archlinux.org/packages/libc%2B%2B/) using Clang.
I get the error /usr/bin/ld: cannot find -lc++
The error is independent from the code, it appears even in a "Hello World".
If I remove the -static option it compiles (and links) and the generated executable works.
I don't want to use libstdc++ (I have my reasons not to please not focus the discussion in this) and the linking must be static (it's a requirement).
I'm perfectly aware that it's difficult to debug this stuff without having access to the machine where it happens. However, it happens it two different machines (both with Arch) so maybe it's something I'm forgetting about.
What I have tried so far is explained here (https://releases.llvm.org/7.0.0/projects/libcxx/docs/UsingLibcxx.html)
The basic command that shoud work it's the following
clang++ -static -stdlib=libc++ -std=c++17 main.cpp -lc++abi
That will be because you do not have a static libc++ (i.e. libc++.a) installed
on your system. Archlinux defaulted to not installing static libraries 5 years ago,
so it will be challenging for you to perform fully static linkages. You will
have to make your own static builds of all dependent libraries, recursively.
I installed arm-linux-gnueabihf via sudo apt-get install arm-linux-gnueabihf and i want to do cross compile for Raspberry Pi.
My make file is like that:
arm-linux-gnueabihf-g++ *.cpp *.h b64.c -o file -lcurl -lcrypto -lpthread -lssl
and an error occured like that:
/usr/arm-linux-gnueabihf/bin/ld: cannot find -lcurl
/usr/arm-linux-gnueabihf/bin/ld: cannot find -lcrypto
Also I tried to link with -L/usr/lib/x86_64-linux-gnu/libcurl.so but it is still same error.
Also i don't understand why libssl a is linked but others do not.
How can I link these libraries to arm-linux-gnueabihf?
Thank you.
You cannot link x86-64 bit libraries with arm-linux-gnueabihd.
You need to get gnueabihf libraries of curl and crypto.
One way: cross-compile curl and crypto libraries, use -L to specify directories where cross-compiled libcurl.so and libcrypto.so for gnuaebihf machine reside.
Another way: copy libcurl.so and libcrypto.so from raspberrypi onto your computer, specify directory where they reside with -L and try to compile, it should work.
ssl and pthread is linked, because you provide ssl and pthread libraries compiled for gnueabihf architecture. Look in /usr/arm-* for those files, probably in /usr/arm-linux-gnueabihf/lib.
Generally, for beginners, just compile your program on your raspberry pi (with curl and crypto installed), it will spare you much trouble.
The line -L/usr/lib/x86_64-linux-gnu/libcurl.so is invalid. You don't specify file using -L command line, you specify directory which contains libcurl.so. Also you specified directory with x86-64 architecture specific libraries while using gnueabihf compiler, they will not work, they are not compatible, no. You cannot link x86_64-linux-gnu/libcurl.so or any x86-64 library with a gnueabihf program.
The whole idea of crosscompiling is that you compile for another architecture. You don't mix those architectures, as they are not compitable with each other, just like you can't run x86-64 program on you raspberry pi, and you can't run a rapberry pi program on you computer. The machine codes of two architectures are not compatible with each other.
When you compile a program for gnueabihf architecture, you need to link gnuabihf libraries and use gnuabihf object files and use a compiler that will generate gnueabihf specific machine code. When you compile program for x86-64 machine, you need to link x86-64 libraries and use x86-86 object files and use a compiler that will generate x86-64 machine code.
Probably it may be also worth to you, use file command to determine file type. You may run file /usr/lib/x86_64-linux-gnu/libcurl.so to see that this libcurl.so is a x86-64 shared object.
I wrote some custom c++ code and it works fine in ubuntu, but when I upload it to my server (which uses centos 5) its fails and says library is out of date. I googled all around and centos cannot use the latest libraries. How can I compile against the stl so that it is included in the binary and it doesn't matter that centos uses an old library?
P.S. I don't want to upload the source to the server and compile there.
In your linking step, you can simply add the "-static" flag to gcc:
http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Link-Options.html#Link-Options
You may install on your Ubuntu box the compiler that fits the version of the library on your server.
You may ship your application with libstdc++.so taken from the system you compiled it at, provided you tune the linking so it gets loaded instead of centos' one.
You may compile it statically. To do this, you should switch your compiler from g++ to
gcc -lgcc_s -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
Choose whatever you like. Note that approaches (2) and (3) may arise the problem of dependencies: your project (particularly, the stdc++ implementation that, being statically linked, is now a part of your app) may require some functions to present in the system libraries on centos. If there are no such functions, your application won't start. The reason why it can happen is that ubuntu system you're compiling at is newer, and forward compatibility is not preserved in linux libraries.
When building a application that accesses a MySQL database on linux using C/C++ i have to dynamically link into the mysql client library. Is there a way in which i can statically link the application so that the mysql client libraries are no longer required?
What is the best practice, with regards to C\C++ development, to include rather long queries in the application but outside the code? Using stored procedures an not possible as the database runs on a MySQL 4 server.
Should be easy to create the static mysql client libs. If you downloaded the source, you just need to make sure you configure it appropriately:
./configure --enable-static
This should build libmysql/libmysqlclient.a (or possibly libmysql/.libs/libmysqlclient.a) which should be easy to link statically into your executable.
You'll need your executable to be licensed under the GPL or you'll need to buy an appropriate license from the MySQL folks.
The following compile command-line worked for me to statically link the mysql client libs:
gcc -I/usr/include/mysql -c mysql.c
gcc -o mysql mysql.o -static -lmysqlclient -static-libgcc -lm -lz -lpthread
However, I received the following warnings, which may or may not be a problem for you. It seems to be saying that there is a dependency on the target machine having the same glibc version as your build machine.
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/libmysqlclient.a(mf_pack.o): In function `unpack_dirname':
(.text+0x6cc): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/libmysqlclient.a(libmysql.o): In function `read_user_name':
(.text+0x5ed7): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/libmysqlclient.a(mf_pack.o): In function `unpack_dirname':
(.text+0x6e1): warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/libmysqlclient.a(my_gethostbyname.o): In function `my_gethostbyname_r':
(.text+0x3c): warning: Using 'gethostbyname_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/libmysqlclient.a(libmysql.o): In function `mysql_server_init':
(.text+0x695d): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking