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.
Related
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.
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.
I am attempting to port an application to an arm processor and have run into a roadblock. I don't get to change the source code and it uses a feature that is not available in the arm runtime on the arm host. I get the message on the arm host:
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version 'CXXABI_1.3.8' not found (required by MyDaemon);
I ran
strings libstdc++.so.6 | grep CXXABI and got the list with the last element as CXXABI_1.3.6.
Can I simply replace the toolchain/runtime on the arm machine or do I have to worry about other programs that link to it and will not run any longer?
g++ --version gives (Debian 4.6.3-14) 4.6.3
so maybe I can use a 4.9 toolchain and runtime?
The issue with that answer is that when the different libstdc++ is loaded it reports.
GLIBC_2.17 not found
The problem is that the environment on the machine where the application is compiled is different from the environment where the application is run and would like to know where to read to be able to solve this problem.
After I installed the gcc cross compiler on my ubuntu, I noticed a few new packages.
arm-linux-gnueabihf-g++
arm-linux-gnueabihf-g++-4.8
Both packages compile my code correctly. I suspect that one compiler is a version independent (ie once i install version 4.9 this package would still be named as it is) and one is specifically for version 4.8 only.
What could be the difference between the following two packages and which one I should use to cross compile in eclipse?
I develop a CGI C++ application that I compiled under Debian. Running this app on an Ubuntu system I am getting the error:
relocation error: /lib32/libresolv.so.2: symbol strlen, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
What can I do now? Should I recomile on the Ubunto system? Can I replace a library?
Edit
I link my application with -static.
Running the command ldd --version on the Ubuntu system showed my that EGLIB is used there.
What this error means is that your program was compiled/linked against an older version of GNU libc, which is not supported on the system where you want to run your executable.
You have few options to solve it:
Make sure you use the same or compatible version of libc when compiling and running.
Link against a static runtime.
Install older version of libc on Ubuntu system to match the Debian's environment.