I am working on a project where we use an old version of libstdc++. I have just introduced a new library statically linked, that requires a newer version of the libstdc++. I have installed both versions of libstdc++ installed. Is there a way to compile my program with gcc and the new library?
Compile with the newer version of libstdc++ as this library is forward compatible.
Related
I am writing an application and I would like to use GCC 4.8 on rhel7. My problem is that I need to use a 3rd party shared lib which was built using GCC 4.4 built on rhel6.
Someone suggested I create an interface between my app
and the library using extern "C" to avoid ABI issues of going between c++03
to c++11, and only pass simple C structs in the interface.
That's a meaningful suggestion as it's too hard to preserve ABI compatibility in C++ interfaces.
But they also suggested its possible I might have to copy and link
libstdc++ and libgcc from the rhel6 machine since the 3rd party lib
(and my interface) is built using those. This is where I am confused.
Both libgcc and libstdc++ preserve backwards compatibility (unless in GCC5 but that's not your case) so the 3rd party lib should work just fine with RHEL7 libs.
Given that the major version (libName.so.major.minor.x.z) of libstdc++
and libgcc is the same on rhel6 and 7, do I really need to copy them
from rhel6 to 7?
No (see above).
Cant I build my interface on rhel6, and just copy it along
with 3rd party lib to rhel7 (without copying old libstdc++/libgcc)?
Yes, this will work.
I mean, since stuff built using old libstdc++/libgcc
should be forward compatiable, no?
Correct (they usually say that "new versions of standard libs are backwards compatible i.e. software compiled with older libs will continue to work").
Can I run into issues (ABIs)?
If you somehow manage to pass STL object created in one libstdc++ to another you'll have weird errors. But if both your and 3rd party library have pure C interfaces this should not be an issue (as there's no way for STL objects to escape their containing libraries).
If I do need to copy libstdc++ and libgcc from rhel6,
and link new and old versions together -- how do i do that?
will there suggestion of statically linking the new versions work?
This would be unnecessary burden.
I have an old application framework that must be compiled with gcc 4.4.4 and an old libstdc++.so, which don't support C++14.
I want to use gcc 6.2 to write my new functions in C++14, and compiled them into a static library myslib.a.
myslib.a exports its functions only in pure C interfaces for ABI compatibility.
My issue is: The framework uses an old libstdc++.so, which is not compatible with C++14.
Is it possible to enforce myslib.a to statically link the latest libstdc++.a and ignore the older libstdc++.so?
I am now currently working on a C++ project, which I wish to use C++11 features with. In this project, I am using the library NTL which is used for number theory stuff.
Due to comfort auto completes Xcode has, I write my code with Xcode and the library NTL is statically linked with flag "-lntl".
Now, I wish to use some C++11 features. Apple's LLVM compiler that is default in Xcode includes such support, but somehow compiling with NTL and iostream doesn't work, unlike with the LLVM GCC 4.2 compiler with Xcode.
And so, I use LLVM GCC 4.2 compiler, but it does not include support for C++11. Therefore, I brew'd gcc48, and I wish now to make Xcode compile its code with gcc4.8.
How can I do that?
--EDIT--
Solved thanks to all comments which advised to change from libc++ to stdlibc++ (GNU libc++) and that solved the problem of NTL not being compiled with Clang.
There are 2 different implementation of C++ run-time library: gcc's libstdc++ and clang's libc++ which are incompatible with each other.
Change the use from libc++ to libstdc++.
I have the following setup.
A redhat 4 machine with libstdc++ (old) installed under /usr/lib and an older version of gcc installed to the default location.
We also have a newer version of gcc 4.4.5 installed in a different directory with a newer version of libstdc++.
When I build a program with 4.4.5 and try to run I get errors indicating that I am using an older version of libstdc++.
Is there a way I can make the new compiler link against the system libstdc++ installed at /usr/lib instead of the one it comes with.
Thanks in advance
(I know it's an old question, this is for fellow googlers)
It seems that gcc is closely tied to its standard includes and standard lib. Their pathes are even hardcoded in gcc executables so gcc vX should automatically pick its corresponding files (includes + standard lib) that were built alongst itself (option --prefix in the ./configure command before the build) unless overriden.
The gcc standard C++ lib is shipped with gcc and built with the same command.
So it is not possible/recommanded to use non matching standard lib and compiler versions, unless with luck if the changes are minor.
Why do you want the new compiler to link against the old libstdc++? The problem sounds like its the new compiler using the old library already because it doesn't know where its is. Specify the path in LD_LIBRARY_PATH.
export LD_LIBRARY_PATH="/path/to/my/new/lib:${LD_LIBRARY_PATH}"
I am working on redhat 5.2 on a project which spans several disparate organizations. Each organization delivers libraries which have been compiled with various versions of g++. Currently, these versions include 4.1.1, 4.1.2 and 4.3.1. I am trying to link all the libraries together into an executable using 4.1.2. What, if any, problems may I expect by doing this? As an aside, is there a way to tell which ABI each compiler version builds to?
This ABI policy document details the compatibility between different ABI versions.
According to that, the libstdc++.so library should be compatible, and the last time gcc broke binary compatibility was at 3.4. You should be fine.
GCC (GNU Compiler Collection) defines version numbers and compatibility.
The G++ libraries between 4.1.1 and 4.1.2 should be compatible; link with the newest.
The G++ libraries between 4.1.x and 4.2.x are not compatible; you need to recompile something.
The G++ libraries between 3.x.y and 4.p.q are not compatible; you need to recompile something.
In your scenario, the code built with 4.3.1 is not compatible with the rest.
Either you will have to rebuild the code currently compiled with 4.3.x so it uses 4.1.x, or you need to recompile the code currently compiled with 4.1.x so it uses 4.3.x instead.
Maybe it is easier to static link the executable... makes a big binary, but runs on all platforms.
There should be no problems linking libraries built from different versions of g++ unless they've been listed on the g++ website. What is important though is that these libraries be built on the same platform which in your case is redhat 5.2. A library built for a platform other than linux/redhat (say solaris) will not link with your exe.
IIRC, there is a C++ compatibility library that is used to do just that. I think it's called libstdc++-compat.