When enabling C++11 with stdlibc++ 4.7, clang error out, while gcc compiles fine

Question

I have been trying to get C++11 to work, after browsing different websites and Q/A, i am still having trouble with. I want to use clang with libstdc++. It is indicated in the clang status that it's supported with patch - http://clang.llvm.org/libstdc++4.7-clang11.patch. I download the gcc4.7 from macports and made corresponding changes in the headers for gcc4.7

The reason that i don't uses libc++ is because ABI compatibilities between libc++ and libstdc++, indicated by this thread: Why can't clang with libc++ in c++0x mode link this boost::program_options example?

OK, after everything is done, i tested my setup with the following code:

#include <mutex>
#include <thread>

int main ( ) {
    std::mutex myMutext;
    return 0;
}

I am expecting that include should work under c++11.

So here is how I compile it with: with GCC

g++ -std=c++11 -I/opt/local/include/gcc47/c++ -L/opt/local/lib/gcc47 main.cpp -o main

Compile successfully

with Clang

clang++ -std=c++11 -I/opt/local/include/gcc47/c++ -L/opt/local/lib/gcc47 main.cpp -o main

I am getting this error:

@work:boostTest$ clang++ -std=c++11 -I/opt/local/include/gcc47/c++ -L/opt/local/lib/gcc47 main.cpp -o main
In file included from main.cpp:1:
In file included from /opt/local/include/gcc47/c++/mutex:38:
In file included from /opt/local/include/gcc47/c++/tuple:37:
In file included from /opt/local/include/gcc47/c++/utility:70:
/opt/local/include/gcc47/c++/bits/stl_relops.h:72:3: error: unknown type name '_GLIBCXX_BEGIN_NAMESPACE_VERSION'
  _GLIBCXX_BEGIN_NAMESPACE_VERSION
  ^
/opt/local/include/gcc47/c++/bits/stl_relops.h:86:5: error: expected unqualified-id
    template <class _Tp>
    ^
In file included from main.cpp:1:
In file included from /opt/local/include/gcc47/c++/mutex:38:
In file included from /opt/local/include/gcc47/c++/tuple:37:
In file included from /opt/local/include/gcc47/c++/utility:71:
In file included from /opt/local/include/gcc47/c++/bits/stl_pair.h:61:
/opt/local/include/gcc47/c++/bits/move.h:38:1: error: unknown type name '_GLIBCXX_BEGIN_NAMESPACE_VERSION'
_GLIBCXX_BEGIN_NAMESPACE_VERSION
^
/opt/local/include/gcc47/c++/bits/move.h:45:3: error: expected unqualified-id
  template<typename _Tp>
  ^
In file included from main.cpp:1:
In file included from /opt/local/include/gcc47/c++/mutex:38:
In file included from /opt/local/include/gcc47/c++/tuple:37:
In file included from /opt/local/include/gcc47/c++/utility:71:
In file included from /opt/local/include/gcc47/c++/bits/stl_pair.h:61:
In file included from /opt/local/include/gcc47/c++/bits/move.h:57:
/opt/local/include/gcc47/c++/type_traits:41:1: error: unknown type name '_GLIBCXX_BEGIN_NAMESPACE_VERSION'
_GLIBCXX_BEGIN_NAMESPACE_VERSION
^
/opt/local/include/gcc47/c++/type_traits:55:3: error: expected unqualified-id
  template<typename _Tp, _Tp __v>
  ^
/opt/local/include/gcc47/c++/type_traits:65:11: error: unknown type name 'integral_constant'
  typedef integral_constant<bool, true>     true_type;
          ^
/opt/local/include/gcc47/c++/type_traits:65:28: error: expected unqualified-id
  typedef integral_constant<bool, true>     true_type;
                           ^
/opt/local/include/gcc47/c++/type_traits:68:11: error: unknown type name 'integral_constant'
  typedef integral_constant<bool, false>    false_type;
          ^
/opt/local/include/gcc47/c++/type_traits:68:28: error: expected unqualified-id
  typedef integral_constant<bool, false>    false_type;
                           ^
/opt/local/include/gcc47/c++/type_traits:71:36: error: expected ';' after top level declarator
    constexpr _Tp integral_constant<_Tp, __v>::value;
                                   ^
/opt/local/include/gcc47/c++/type_traits:83:14: error: expected class name
    : public false_type
             ^
/opt/local/include/gcc47/c++/type_traits:106:14: error: expected class name
    : public true_type
             ^
/opt/local/include/gcc47/c++/type_traits:126:14: error: unknown template name 'integral_constant'
    : public integral_constant<bool, !_Pp::value>
             ^
/opt/local/include/gcc47/c++/type_traits:126:38: error: expected class name
    : public integral_constant<bool, !_Pp::value>
                                     ^
/opt/local/include/gcc47/c++/type_traits:142:14: error: expected class name
    : public false_type { };
             ^
/opt/local/include/gcc47/c++/type_traits:146:14: error: expected class name
    : public true_type { };
             ^
/opt/local/include/gcc47/c++/type_traits:151:14: error: unknown template name 'integral_constant'
    : public integral_constant<bool, (__is_void_helper<typename
             ^
/opt/local/include/gcc47/c++/type_traits:151:38: error: expected class name
    : public integral_constant<bool, (__is_void_helper<typename
                                     ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

I am using clang version:

Apple clang version 4.0 (tags/Apple/clang-418.2.41) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix

Am I doing something wrong? or is this a clang problem with latest gcc 4.7 libstc++?

You are explicitly `-I`-ing gcc-4.7 internal headers into a `clang` compile; I would not expect this to work sensibly. — geekosaur, Apr 25 '12 at 01:26
if I do this: I also see error. @work:boostTest$ clang++ -std=c++11 -L/opt/local/lib/gcc47 main.cpp -o main main.cpp:1:10: fatal error: 'mutex' file not found #include 1 error generated. — Negative Zero, Apr 25 '12 at 01:40
Which OS are you using ? On most OSes Clang should be able to automatically find the GCC headers. If it does not for your OS, then the driver logic should be adapted. — Matthieu M., Apr 25 '12 at 08:19
I am using Mac OS 10.7.3. The GCC 4.7 are downloaded through macports. (Mac OS 10.7.3 shipped with GCC 4.2.1) — Negative Zero, Apr 25 '12 at 18:00
"The reason that i don't uses libc++ is because ABI compatibilities between libc++ and libstdc++," normally not mixing standard library implementations is important for exactly the reason you mention, however libc++ uses inline namespaces so that it's perfectly safe to mix libc++ and libstdc++. If there's a problem you'll get a build failure and you can try to resolve it some other way. — bames53, Apr 25 '12 at 18:37
i am not sure what you mean by mixing. Are you suggesting that I can link both libc++ and libstdc++? — Negative Zero, Apr 28 '12 at 00:52

score 8 · Accepted Answer · answered May 06 '12 at 13:32

8

Why are you saying -I/opt/local/include/gcc47/c++ ?

That should not be necessary with either GCC or Clang, and will not work. Not all libstdc++ headers are under that path, there are some essential headers elsewhere that define things like _GLIBCXX_BEGIN_NAMESPACE_VERSION

It doesn't fail with GCC because GCC already knows how to find the other headers, so it's redundant to explicitly use -I and -L options. It doesn't work with Clang because you are only telling it how to find some of the headers it needs, but not telling it how to find the rest.

Stop trying to override the compiler's standard library paths, let it use the built-in paths it already knows about.

answered May 06 '12 at 13:32

Jonathan Wakely

166,810
27
341
521

I have the same problem. Our problem is that Clang uses the system's GCC for its libraries and headers. We want to use an **independent** installation of GCC (the ones from MacPorts) as Clang's base. How do we tell Clang to look elsewhere for GCC, that the compiler it's using for the "standard library paths" is *wrong*?! (Responses given to similar queries, such as "install libc++" or "hard-code the new path and recompile clang," would be useless here.) – CTMacUser May 12 '12 at 01:54
2

@CTMacUser, You need to rebuild clang, using `--with-gcc-toolchain` to tell it where to find the GCC headers and libs. You _might_ be able to override the paths for your existing installation with very careful use of lots of `-I` and `-L` options but you need to override **all** the relevant paths. Compile with `gcc -v` to see all the standard search directories GCC uses, which you'd also need to tell Clang to use. Even then it might not work (clang has some hardcoded paths that are set when you install it and I don't know if they can be overridden) – Jonathan Wakely May 23 '12 at 16:41
@JonathanWakely Would setting the environment variable `CPLUS_INCLUDE_PATH` (and `CPATH`) not work (instead of rebuilding clang)? – Walter Apr 01 '13 at 10:04
@Walter, not unless you also override its library paths. It would also have the same problem as using `-I/opt/local/include/gcc47/c++`, i.e. not all headers are in that directory, so you have to know all the relevant directories and be sure to provide them all in the right order. – Jonathan Wakely Apr 01 '13 at 11:49
@JonathanWakely yes, but I would use the output from `gcc -v -x c++ /dev/null -fsyntax-only` to get all the include paths needed. – Walter Apr 01 '13 at 12:02

score 7 · Answer 2 · answered May 23 '12 at 06:28

I'm using clang-3.1 with gcc4.6 libstdc++ on FreeBSD 9.0/AMD64. It works with these options:

-I/usr/local/lib/gcc46/include/c++ \
-I/usr/local/lib/gcc46/include/c++/x86_64-portbld-freebsd9.0 \
-L/usr/local/lib/gcc46

I guess your problem may be solved to use these options:

-I/opt/local/include/gcc47/c++ \
-I/opt/local/include/gcc47/c++/x86_64-apple-darwin11.3.0 \
-L/opt/local/lib/gcc47

score 1 · Answer 3 · answered Jan 14 '16 at 15:03

You can use the special option -gcc-toolchain, which is implicitly set by --with-gcc-toolchain when you compile clang. It's a bit easier than recompile clang when you want to use another GCC libraries :)

Like that:

~/clang/trunk/bin/clang++ main.cc -gcc-toolchain ~/gcc/trunk -o main

Or, in your case (I know it's 4 years old :)) it seems to be

clang++ main.cpp -o main -gcc-toolchain /opt/local

The 'toolchain' folder should contain 'include' and 'lib' folders. Both compiler and linker use this option. Be careful: --gcc-toolchain is not a valid option, use one dash as the prefix (even though the llvm wiki states otherwise — I checked it on clang 3.8 trunk).

Resurrecting an old thread to tell you how much this helped me. I built every single llvm component and forgot to add the `--gcc-toolchain` flag. — Asher Mancinelli, Feb 18 '21 at 16:02

When enabling C++11 with stdlibc++ 4.7, clang error out, while gcc compiles fine

3 Answers3

Linked