I have a library which is a static library for C and C++.
The problem is that the library is linked against libstdc++.
In Xcode when I switch to libc++ (to use C++11 features and use the mentioned C++ library) it throws many compile errors.
The authors of the library say that the library is not ready for C++11.
Is there still a way to use both?
Your 3-rd party static library should be linked against the same version of the C++ library it was compiled against. This includes not only the type of library (libstdc++), but also major/minor version numbers to ensure ABI compatibility. Any different library version would get you either build breaks in best case, or weird crashes in worst case. Read more about ABI versioning in GCC manual.
If the interface for 3-rd party library only has POD types, you can make a shared library out of your static library, and then use it from your app linked with libc++.
Related
A very simple C++ question that is more aimed at the compilers:
Suppose I create a static library (.lib) or a dynamic linked library (.dll) with the latest Microsoft Visual C++ compiler.
Can I also use such a library directly in GNU C++ compiler projects (within the same operating system) if the header files are available?
That's not compatible with each other, is it? (I'm thinking first of a different ABI etc.)
Many Thanks.
PS: I have an unknown 3rd party library (lib) available. Can I find out here which compiler was used to generate it?
I am having a difficult time configuring an iOS project which uses a static library linked against the old libstdc++ that gcc used. That library is 32 and 64-bit.
There are 6 libraries (libssl.a for example) that are 32-bit and must be updated. If I compile those libraries from source, they will be automatically linked with libc++, which will result in my linker complaining.
Therefore, here are my questions:
1) Is there any way to have a single static library inside the project use libstdc++, and have the others use libc++?
2) How can I compile libraries from source (like libcrypto and libssh) and force them use the old libstdc++ standard library?
3) Is there any other way out of this mess?
1) Yes, you can certainly mix and match which C++ runtimes your C++ code uses so long as those separate modules don't actually pass objects between each-other. For example, if you have two modules in your app which just expose C APIs but internally use C++, then each can use whichever C++ runtime they want. Problems occur when trying to share objects between the runtimes.
2) You can use the '--stdlib=libstdc++' or '--stdlib=libc++' command line argument when compiling and linking to specify which C++ library to use. If your final executable needs to link against both, you'll need to manually specify the other one (eg: --stdlib=libc++ -lstdc++).
3) Yep, but note that libstdc++ was deprecated years ago and isn't even available on watchOS nor tvOS, so your best bet is to just get everything over to libc++.
As long as you don't mix objects (like passing a string from one library into a function that expects a different kind of string), you can do it by including both libraries when you build the top-level app.
In my case, it worked by setting the standard C++ lib to the GNU version and then adding libc++ as I would any other system library.
Having gone through a number of similar questions (see below), I don't think any of them cover this case.
Problem
Is it possible to dlopen and use a C++11 shared library compiled using gcc 4.9 from a C++03 application compiled with gcc 4.1? Both the library and application use libstdc++, including on the API (but not std::list, which is apparently a problem). I can't change the way the application is compiled (sadly), and must be certain that existing code doesn't break (e.g. if it ends up dynamically linking to a new version of libstdc++.so).
As far as I understand it (which is not very), on Linux the dynamic linker uses a flat namespace, meaning that is not possible to have the same symbol defined in two libraries. Does statically linking the library against the newer libstdc++ help at all here, or is there perhaps some other way?
Some similar questions that don't seem to answer this
C++11 backwards compatibility
C++03 library with C++11 source code
C++11 compatibility with existing libraries/frameworks
Can a compiled C++11 library (lib,dll,etc.) be linked in older C++ compilers? [softwareengineering.stackexchange.com]
If you do that, you definitely need to use the newer libstdc++.so.6, which should be compatible with the system libstdc++.so.6 based on GCC 4.1 (in the sense that GCC upstream intends to preserve ABI compatibility for the library). It would be a very good idea to use the libstdc++.so.6 library that came with the GCC 4.9 compiler.
Once you do that, it is supposed to work, unless you hit the few of the compatibility gotchas you already listed, and as long as the C++ part of the library interface actually sticks to the C++98 subset and does not use any constructs which are not expressible in the language subset.
All this assumes that the library was actually compiled on the the system which uses GCC 4.1, which probably has something like glibc 2.5. If the library was compiled on a completely different, newer system, then you will likely run into library compatibility issues beyond libstdc++.so.6, and these libraries tend to be even harder to upgrade.
(There is also the possibility that the library was explicitly compiled for use with the 4.1-based system libstdc++.so.6 and everything just works, just as if by magic, but then you wouldn't be asking here, I suppose.)
If you still have problems there is the option to use a statically linked C-API library as border between the two, application and your library, see this post.
Also you may be able to explicitely demand an old version of a symbol, see this post
I'm working on an app where I need to use two c++ based frameworks and I can't find how to configure build settings so they both build.
One of them works with C++ Standard Library libc++, the other one, with libstdc++.
Is there a way to specify a c++ library by framework? Or at least, a main c++ library and an exception for the other?
Thanks.
Ensure that C++ Standard Library is set to libstdc++ (GNU c++ standard library) in the Apple LLVM 5.0 Compiler Build Settings
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.