There are existing two include paths（5.4.0， v1） and two libraries(libstdc++, libc++) for C++ project in QNX7.
When using v1 path, it looks like libc++ should be used only.
I want to know the difference of them and features.
Actually QNX 7 supports both libstdc++ (GNU) and libc++ (LLVM). Both libraries implement c++ standards and are used widely. You can choose which library to link against on compiling time.
For more info see: http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.qnxsdp.migration/topic/cpp_apps.html
and http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.utilities/topic/q/qcc.html
Related
The common explanation for not fixing some issues with C++ is that it would break the ABI and require recompilation, but on the other hand I encounter statements like this:
Honestly, this is true for pretty much all C++ non-POD types, not just exceptions. It is possible to use C++ objects across library boundaries but generally only so long as all of the code is compiled and linked using the same tools and standard libraries. This is why, for example, there are boost binaries for all of the major versions of MSVC.
(from this SO answer)
So does C++ have a stable ABI or not?
If it does, can I mix and match executables and libraries compiled with different toolsets on the same platform (for example VC++ and GCC on Windows)? And if it does not, is there any way to do that?
And more importantly, if there is no stable ABI in C++, why are people so concerned about breaking it?
Although the C++ Standard doesn't prescribe any ABI, some actual implementations try hard to preserve ABI compatibility between versions of the toolchain. E.g. with GCC 4.x, it was possible to use a library linked against an older version of libstdc++, from a program that's compiled by a newer toolchain with a newer libstdc++. The older versions of the symbols expected by the library are provided by the newer libstdc++.so, and layouts of the classes defined in the C++ Standard Library are the same.
But when C++11 introduced the new requirements to std::string and std::list, these couldn't be implemented in libstdc++ without changing the layout of these classes. This means that, if you don't use the _GLIBCXX_USE_CXX11_ABI=0 kludge with GCC 5 and higher, you can't pass e.g. std::string objects between a GCC4-compiled library and a GCC5-compiled program. So the ABI was broken.
Some C++ implementations don't try that hard to have compatible ABI: e.g. MSVC++ doesn't provide such compatibility between major compiler releases (see this question), so one has to provide different versions of library to use with different versions of MSVC++.
So, in general, you can't mix and match libraries and executables compiled with different versions even of the same toolchain.
C++ does not have an ABI standard as of yet. They are attempts to have it in the standard; You can read following it explains it in details:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf
I want to use parallel sort from c++17's standard library in my cmake project (it's cross platform and works great on Linux and MSYS2) but Apple Clang's libc++ has not implemented it yet, while gnu's libstdc++ has. How do you use gnu's implementation of c++17's libraries in a cmake project on mac?
The solution I found is to build gcc from source and use that compiler and the libraries that come with it. It also needs to be static linked with -static-libgcc -static-libstdc++. I also had trouble with the fmt library after switching to the gnu standard library, but resolved that by using the header-only version of fmt.
Here's the CMakeLists.txt file with the complete details.
Probably the best way to parallelise on a Mac is to follow the advice given by Apple - use dispatch calls.
I posted an example at C++11 app that uses dispatch_apply not working under Mac OS Sierra
This uses dispatch_apply - pretty much a drop-in for a for-to loop.
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