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++.
Related
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 have to use unordered_map and trie, but not one standard library, nor another one contains both of them.
// works only with LLVM library
#include <unordered_map>
// works only with GNU library
#include <ext/pb_ds/assoc_container.hpp>
I mean which is described on the GCC GNU website.
The program is building in Xcode 7.2.1. I have tried to use GNU C++14, GNU C++11 and C++14, C++11, but it doesn't help.
How this problem may be solved? Probably, my GNU library is too old, can I update it in Xcode? Or, maybe, LLVM has assoc_container.hpp is some other path?
std::unordered_map came in with the C++11 standard, and not all compilers use C++11 (or later) as standard yet meaning you have to add flags when building to be able to use it.
When building with GCC versions prior to 5.1 you should add the flag -std=c++11 (or optionally -std=gnu++11 if you want GCC extensions, or -std=c++0x if you have a really old version of GCC).
An implementation of std::unordered_map is a requirement for C++11. This suggests you are using an older version of stdlibc++.
If you're stuck with that version, Boost provides an implementation that you could use.
You can't expect libc++ (Clang's C++ library) to have GNU extensions. You can, however, mix and match libstc++ and libc++ in the same executable (but not compilation unit) due to the latter's use of inline namespaces, which mean that its symbols won't clash with the former.
Edit:
Seems the OP is compiling on MacOSX using a recent version of clang.
In this case, the libstd++ shipping with the toolchain is a creaking old version without C++11 support. It is deprecated as far as Apple is concerned.
The best bet is to either: modify code to avoid use of extensions in libstdc++ - which in any case appear to C++11 pre-release features
or: build with both libraries (yes, this is totally possible on MacOSX and iOS). Caveat here is that you can only ever use one or the other in any compilation unit.
Apple's clang appears to magically include Xcode header files which conflict with my code. For example, they define stoi() while standard C++ headers do not. Clang does not do this on other platforms, e.g. FreeBSD.
Example of error on Mac OS:
$ clang -I. -I../../../include -c compile.cpp
compile.cpp:949:18: error: call to 'stoi' is ambiguous
arg.iValue = stoi(current.token);
^~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:4019:37: note:
candidate function
_LIBCPP_FUNC_VIS int stoi (const string& __str, size_t* ...
^
This compile works fine on FreeBSD.
The problem is because in addition to the standard C++ headers in /usr/include/c++, Apple clang is including the headers in the Xcode application tool chain. Is there some way to turn that off without using the -nobuiltininc flag?
The default C++ library for newer versions of clang on OSX is libc++, which is a pretty full implementation of the C++11 standard. The headers are all C++11, and there are no conditional sections to remove methods that should only be available in that standard (e.g. attempting to compile using --std=c++03 doesn't have the desired effect.
The version of stdlib++ that's present in the apple environment doesn't have this issue as (1) it's not a complete implementation of the C++11 standard, and (2) you can actually compile for older c++ standards.
As a result, if you compile using --stdlib=libstdc++, you are compiling against the GNU standard library headers and library which don't have the issue with the definition of std::stoi (and others routines if I'm interpreting the question correctly).
Bear in mind, though, that you have to compile every c++ element of your project with this flag, as otherwise you end up with code that has been compiled with different standard libraries and they will not link together.
The real problem, though, is that if you start using C++11 features and start compiling explicitly with --std=c++11, then you're probably going to encounter this problem at some point in the future with gcc as well. Newer versions of the compiler support more of the C++11 standard, and so would define this routine in the headers and you're back to square one.
I have a few static libraries, which I'm not the owner of, compiled with an old version of g++ 4.3.2 (c++11/c++0x not activated).
When I compile my code with g++ 4.6 (no c++11) and link it using g++ 4.6 with these
static libraries, it links fine and I do not seem to get any issues at runtime (not tested everything though).
I'm tempted to think that forward compatibility is OK.
Now I'd like to compile my code with gcc 4.8 with c++11 and still link it with those same, not recompiled static libraries.
Are ABI changes in g++ only an issue for linkage forward compatibility or can one get backward compatibility issues too?
The G++ ABI for C++98 code is backward compatible, all the way back to GCC 3.4
So if you compile and link your final executable with GCC 4.8 you can link to objects and libraries built with anything from GCC 3.4 to 4.8 (but no newer)
The C++11 ABI is the same as the C++98 ABI and the standard library types that are common to both C++98 and C++11 have the same definitions, (ignoring GCC 4.7.0 and GCC 4.7.1, which had ABI incompatibilities in std::pair and std::list when using C++11, which have been fixed in 4.7.2 and later versions) so you can link C++98 and C++11 code together (unless the C++11 code was built with GCC 4.7.0 or 4.7.1)
However some C++11 library types are not stable yet and change between releases, e.g. because they were first shipped before the final C++11 standard and had to be changed to match the final rules. So it's not necessarily safe to mix C++11 code built with GCC 4.6 and C++11 code built with GCC 4.8
For your case, where all the C++11 code is built with GCC 4.8 that will be OK. If you upgrade the compiler you should rebuild all the C++11 code with the newer GCC to be safe. (You don't need to rebuild the C++98/C++03 code)
The C++11 standard has as it's goal to maintain backwards compatibility, as does compiler vendors. As long as the library doesn't use anything that "breaks" C++11 standard, the library format itself should be the same.
See this for changes introduced in C++11.
So, presuming the code you are using to call the library (including headers), you should be fine.
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