After upgrading to gcc-11, which is shipped with Ubuntu 22.04, I started to get new compiler errors due to some missing Standard Library header files. Whereas previous gcc versions don't.
When I started to look into it, I learned from Porting to GCC 11 page, under the "Header dependency changes" section, that this is a new behavior due to some new specs in the standard itself.
Now, my question is: does the implementation of a particular C++ standard (i.e. C++17) change from one gcc version to another (i.e. gcc-9 and gcc-11)? I mean, how can the build fail if I'm building with different gcc versions but against the same C++ standard version (i.e. -std=c++17)?
And is that C++ Standard Library new requirement - of not to include other headers that were being used internally by the library - part of C++17 or C++20?
To get over this...
I manually included those header files where they were missing, and the build just succeeded.
However, I was expecting behavior to be consistent when I build against a certain C++ version with different gcc versions. Or, am I missing something?
Thanks to JaMiT note, I realized that I got the note from GCC wrong.
It's only their implementation of the Standard that got changed in GCC 11, and not the Standard itself.
When you thoroughly read the referenced section from that article, you can see that.
Header dependency changes
Some C++ Standard Library headers have been changed to no longer
include other headers that were being used internally by the library.
As such, C++ programs that used standard library components without
including the right headers will no longer compile.
The following headers are used less widely in libstdc++ and may need
to be included explicitly when compiled with GCC 11:
<limits> (for std::numeric_limits)
<memory> (for std::unique_ptr, std::shared_ptr etc.)
<utility> (for std::pair, std::tuple_size, std::index_sequence etc.)
<thread> (for members of namespace std::this_thread.)
Related
Suppose we have a shared library which accepts or returns some kind of std class:
//lib.h
#include <vector>
std::vector<int> returnSomeInts();
//lib.cpp
#include "lib.cpp"
std::vector<int> returnSomeInts() {
return {1, 3, 5};
}
So, obviously, when compiling the shared library lib.so, this code had to be compiled against a particular version of the standard library, for instance with -std=c++11.
Now imagine we have an application which will be using our shared library, but it will be compiled against a newer std library, for example -std=c++2a
//app.cpp
#include <lib.h>
int main()
auto v = returnSomeInts();
//Process v
}
As the standard library defines inline classes, if the layout of the class members changes, ABI compatibility gets broken, so the code above would not work properly.
My questions are: Is there any guarantee for ABI stability with the common implementations of the the std library when compiling against the same header using different c++ standards? And when compiling against different header versions (libstdc++-8 and libstdc++-9 for example)?
PD: The code above is just an example, I am not referring specifically to std::vector
ABIs in practice are not linked to the standard, for example consider this following code compiled with gcc 4.9.4 and gcc 5.1
using the same flags:
-std=c++11 -O2
#include <string>
int main(){
return sizeof (std::string);
}
gcc 4.9.4 returns 8 from main, gcc 5.1 returns 32.
As for guarantees: it is complicated:
Nothing is guaranteed by the standard.
Practically MSVC used to break ABI compatability, they stopped (v140,v141,v142 use the same ABI), clang/gcc have a stable ABI for a long time.
For those interested in learning more:
For a broad discussion of ABI/C++ standard that is not directly related to this question you an look at this blog post.
Your example with std::vector is not a problem. As other answer points out compilers maintain compatibility and std::vector is quite old.
Problem can be new library features of newer C++ standard is used.
For example I have some product which uses C++17 languages features. My product supports MacOS 10.13. I can build my project using C++17 (language features), but I can't use for example std::optional since some methods are throwing std::bad_optional_access which is part dynamic library and this is not supported/present in MacOS 10.13. Clang warns me about that (reports an error).
Same applies on other system (clang nicely controls that). So when you use some library features you need make sure that libraries on deployed system supports that (on Linux package managers handle that nicely if system doesn't have access to required package version installation will fail). On Windows 10 AFAIK Windows update keeps newest version of msvc redistributable, older versions of Windows need manual updates.
Note that many templates are becoming part of your executable and do not have dependencies to shared standard library. Those will not create problems.
These are the kinds of question that the standard doesn't answer, it is down to individual implementers how long they keep compatibility for and which (if any) compiler flags affect compatibility.
In practice libstdc++ on Linux has tried very hard to keep a stable ABI for quite a long time now. The soversion has remained at 6 for around 15 years now.
However there have been some changes, most notable were those introduced with g++-5.1 related to std::list and std::string. New requirements in c++11 meant that to be compliant libstdc++ needed to make breaking changes to the ABI of those classes.
g++'s solution was to define two versions of those classes. To allow both types to coexist in the same shared library they are defined with different names, so the old std::list is defined as std::list while the new std::list is defined as std::__cxx11::list and then aliased as std::list. Which definition is used in a given source file is controlled by a preprocessor macro.
Note that the setting of said preprocessor macro is independent of the -std= setting, you can use the compiler in c++11 mode with the old string/list implementation (in which case it won't be fully compliant with the standard) or you can use the compiler in c++03 mode with the new string/list implementations.
The default value of the macro (if not set explicitly by the user) depends on compiler version and can also be overridden by distribution maintainers.
The trouble is while this solves the problem for libstdc++ it doesn't solve it for all the other libraries. If a program was built with the new implementations while a library was built with the old ones or vice-versa and the library used std::string or std::list in it's API, then the likely outcome was a link failure (it was also possible but less-likely for the linking to succeed but the program to be silently broken). In Debian at least this lead to a massive set of library transitions (it would not surprise me if it was the largest in the project's entire history).
I'm working on a c++ project and I use c++17 as c++ standard. I've some library dependencies which has been developed using c++11. Are there any obstacles in using this library? Do I need to recompile it using c++17 in order to make sure I can use it in my project? I'm using Clang as compiler in my code and the library has been compiled using g++ .
Edit: If I use g++ in both library and my code is there any obstacle in terms of different c++ standards (std11 vs std17)?
Many Thanks,
In general, you should be able to use a C++11 library in C++17 code.
But, you need to remember that C++ does not have a standardized ABI. So the source may be compatible, but any pre-compiled artifacts are likely not.
You have source compatibility, not binary compatibility. This means that - as a rule - you must compile all parts of your project with the exact same compiler. You cannot (as a rule) re-use a library compiled with a different or older compiler with code you compile with a different (or newer) one.
But you should be able to compile that C++11 code with your C++17 compiler (in most cases - there are exceptions).
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 using clang++ (clang-421.0.60), packaged with Xcode 4.6, and came across an issue with boost::spirit. If I compile without any flags, everything compile fine. If I compile with '-std=c++11', then I get the following error (on including of "boost/spirit/include/qi.hpp"):
In file included from test_spirit11.cpp:1:
In file included from /usr/local/include/boost/spirit/include/qi.hpp:16:
In file included from /usr/local/include/boost/spirit/home/qi.hpp:14:
In file included from /usr/local/include/boost/spirit/home/qi/action.hpp:14:
In file included from /usr/local/include/boost/spirit/home/qi/action/action.hpp:21:
/usr/local/include/boost/spirit/home/support/action_dispatch.hpp:21:10: fatal error:
'type_traits' file not found
#include <type_traits>
The problem is that the default library used (stdlibc++) has type_traits defined as 'tr1/type_traits', whereas boost::spirit expects just 'type_traits'. I can of course fix this problem by doing:
clang++ -std=c++11 -stdlib=libc++ <...>
While I would love to use libc++, the practicality of doing so is difficult (many libraries still use and depend on stdlibc++). Thus, I am forced to not use libc++.
Does anyone have any suggestions on how to deal with this? I really wish that either more library maintainers support libc++ or that Apple provided a newer version of stdlibc++. It's been a major frustration to have access to new c++11 features, but not be able to fully use them due to lack of library support.
The problem is that the default library used (stdlibc++)
It's called libstdc++
has type_traits defined as 'tr1/type_traits', whereas boost::spirit expects just 'type_traits'.
<tr1/type_traits> is not the same thing, it's a different header entirely. boost::spirit wants the C++11 header <type_traits> which is a different header (though they do contain some similar functionality, in different namespaces.)
The problem is probably that you're using the libstdc++ that comes with Apple's ancient version of GCC (4.2) which doesn't support C++11.
If you want to use C++11 you either need to use clang with libc++ or install a newer GCC to get a newer libstdc++. Apple won't provide a newer GCC for licensing reasons, but you can install it yourself and tell Xcode how to find the headers and libs.
If you don't want to use C++11 features in boost you can disable it.
Edit boost clang.hpp to manage features.
For example to disable type_traits file not found error you can add to the end:
#define BOOST_NO_VARIADIC_TEMPLATES
I am developing an application in C++11, using g++-4.7 and -std=c++0x.
My app is linked against some shared library compiled with g++-4.7, but without the -std=c++0x directive.
Unfortunately, nothing works, meaning that I have some strange behaviour when using the external library classes and methods. (Of course compiling my app without -std=c++0x works fine).
Is this an expected behaviour or it's a compiler bug?
Any workaround (something like the extern C keyword)?
The standard library has changed, and the -std=c++0x compiler flag will determine what part of the library is in use. By trying to use both versions in the same program you are breaking the One Definition Rule (for each used element in the standard library you have two definitions for the same identifier).
I don't think there is anything simple that can be done to overcome this limitation. You would have to ensure that you only use one version of the library (i.e. define the appropriate macros before inclusion of standard headers to disable C++11 inside those libraries), and even then I am not sure that the generated code would still not break the ODR (if the C++11 extensions compile the C++03 library code differently).