I would like to distribute C++ binary that is created by using Eclipse ++ IDE, with the following settings:
Cross GCC Compiler: gcc -std=c++17
Cross G++ Compiler: g++ -std=c++17
Tool Chain settings:
Cross GCC Compiler
Cross G++ Compiler
Cross GCC Linker
Cross G++ Linker
Cross GCC Archiver
Cross GCC Assembler
I am compiling with boost::serilization and have connect that in Linker. The binary is created on Ubuntu 16.04. I tried to run the binary on Ubuntu 14.04, and it give the error:
error while loading shared libraries: libboost_serialization.so.1.58.0: cannot open shared object file: No such file or directory.
I have also installed libboost on the system by using
sudo apt-get install libboost-program-options-dev
But, it gives me the same error.
I think with the above Eclipse IDE setting, it should work in most of the Linux platforms. Is my presumption of its working on most of the Linux platforms wrong??.
When you build your program you link it with specific versions of the shared libraries. On older releases of e.g. Ubuntu those newer versions of the libraries doesn't exist.
If you want to copy the executable between different systems you need to link statically. That means all libraries are linked into the executable so it doesn't rely on shared libraries. It will make the executable bigger of course.
Related
I have a C++ program which makes use of some C++ standard libraries such as iostream, vector, sstream and so on, and is only about 120 lines of code. By building it on Debian I get a 25KB executable, while when I build it on Windows 11 (both of them with just "g++ main.cpp") I normally get a 3026KB .exe. If instead I type "--shared-libstdc++" alongside g++ on Windows, I get a smaller .exe, merely 290KB.
My question is, why does compiling and linking in a Linux environment automatically do this while on Windows I have to specify it? Is there a drawback to dynamically linking the standard C++ library on Windows that G++ is aware of?
On Windows, I have: gcc version 10.3.0 (tdm64-1)
On Debian, I have: gcc version 11.3.0 (Debian 11.3.0-3)
I am running Linux CentOS 7.3 which comes with g++ 4.8.5. I would like to use g++ 7.1.0 to compile some C++ software. But the C++ program compiled with g++ 7.1.0 is using the headers from the standard library that comes with g++ 7.1.0 and the libstdc++.so which also comes with it which make things really painful.
Is there a way to use g++ 7.1.0 and still use the standard library (both headers and libstdc++.so) from g++ 4.8.5 installed with CentOS?
Is there a way to use g++ 7.1.0 and still use the standard library (both headers and libstdc++.so) from g++ 4.8.5 installed with CentOS?
Don't do that (the ABI of libstdc++ from GCC 4.8 & GCC 7 are likely to be different). Instead consider perhaps linking the C++ standard library (from GCC 7.1) statically (and other libraries dynamically, notably those in C including libc.so, not C++).
BTW, how did you get g++-7.1? You could consider compiling GCC 7 (from its source code) on your CentOS 7 (or get some packaged version of it), then you'll have the right libstdc++
Read more about shared libraries, e.g. read Drepper's paper How To Write Shared Libraries and learn more about the -rpath option passed to ld (often using -Wl,-rpath to g++).
The libstdc++ ABI changed between gcc4 and gcc5 so that's not going to work. If you are using gcc7 you should install libstdc++ 7. You can have both versions installed at the same time
Developer Toolset is designed for this scenario, but it is currently at GCC version 6:
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/
Its C++ compiler has been configured in such a way that the programs it compiles are linked dynamically against the system libstdc++, using a backwards-compatible ABI, and only the library code for new C++ features not yet supported by the system library is linked statically. This gives maximum compatibility and allows compiled applications to run without DTS.
So I'm currently trying to compile something with a newer version of g++ (4.7) than the version of CentOS 6.5.
I'm running supports through yum. I've got a 4.7 g++ binary ready to go, and switched the linking so that /usr/bin/g++ links to the binary I want.
This has been working, but now g++ can't find any of the c++ standard libraries (for instance <algorithm> and <iostream>).
I was wondering how g++ loads these libraries / where these libraries are kept so I can figure out how to get them to properly import!
Thanks!
If you have multiple installations of GCC you can direct the gcc|g++ frontend (/usr/bin/{gcc|g++})
to use the tools, headers and libraries of any of them by means
of the -Bprefix
option, where prefix is an installation prefix.
For example, I have GCC 4.9.3 installed (per distro) with prefix:
/usr/lib/gcc/x86_64-linux-gnu/4.9.3
and also have GCC 5.2.1 installed (also per distro) with prefix:
/usr/lib/gcc/x86_64-linux-gnu/5.2.1
If I invoke:
gcc -B/usr/lib/gcc/x86_64-linux-gnu/4.9.3...
then I'm using the 4.9 tools, headers and libraries. If I invoke:
gcc -B/usr/lib/gcc/x86_64-linux-gnu/5.2.1...
then I'm using the 5.2 tools, headers and libraries. If I omit
-Bprefix then I get my latest installation (5.2).
Hi I am trying to build an executable on Ubuntu for RedHat 6.4 - and I am struggling due to the different gcc versions.
The RedHat 6.4 machine uses gcc 4.4.7. The Ubuntu machine uses gcc 4.6.3.
Here is what I have tried:
Install g++-4.4 on the Ubuntu machine and compile with older version of gcc: failed because the code base uses features not yet available in g++-4.4
Copy the Ubuntu libc.so.6 and libstdc++.so.6 over to the RedHat machine. The program sort of gets started, then segfaults.
Link the executable on Ubuntu statically with -Wl,-Bstatic as link options. Failed on a third party library with "warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking".
So I am a bit stuck now... Any advice?
Based on comments above, decided to dump RedHat (didn't have a subscription, so not easily upgradable) on the other machine and switch to Fedora, which has the latest gcc. Not a solution that scales, but what can you do.
I compiled gcc on one of my ubuntu 10.10 hosts, and installed it in /c. I can compile c and c++ programs fine on that host but when i copy /c (which contains bin, libexec etc) to a ubuntu 10.04.2 host i get:
/c/libexec/gcc/i686-pc-linux-gnu/4.5.2/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory
when compiling a simple .c file.
I've also installed and compiled gmp, mpfr and mpc from source (same versions as i did on the 10.10 host) but it's still coming up with the same error.
The reason i'm not recompiling gcc on each host is because it takes too long, and prefer not to use the gcc (from the build-essential) deb that comes with ubuntu
Please help
did you export your LD_LIBRARY_PATH environment variable? Looking at the error, it's not able to find libmpc.so.2.
Try 'locate libmpc.so.2' and if you can find that,
export LD_LIBRARY_PATH=
Here are some details on how to set LD_LIBRARY_PATH in Ubuntu:
https://help.ubuntu.com/community/EnvironmentVariables#File-location%20related%20variables