2012-04-25 8 views
8

Próbowałem przekonać C++ 11 do działania, po przejrzeniu różnych stron i Q/A, nadal mam problemy z. Chcę użyć clang z libstdC++. W statusie clang jest wskazane, że jest on obsługiwany przez łatkę - http://clang.llvm.org/libstdc++4.7-clang11.patch. I pobrać gcc4.7 z DarwinPorts i wykonane odpowiednich zmian w nagłówkach na gcc4.7Po włączeniu C++ 11 ze stdlibC++ 4.7, błąd clang out, podczas gdy gcc kompiluje dobrze

Powodem, że nie używa libC++ dlatego Kompatybilność ABI pomiędzy libC++ i libstdC++, oznaczone tym wątku: Why can't clang with libc++ in c++0x mode link this boost::program_options example?

OK, gdy wszystko jest zrobione, przetestowane mój setup z następującego kodu:

#include <mutex> 
#include <thread> 

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

spodziewam się, że to powinno działać pod C++ 11.

Więc tutaj jest jak skompilować go z: GCC

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

kompilacji powodzeniem

z Clang

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

ja dostaję ten błąd:

@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. 

używam wersji clang:

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 

robię coś źle? lub czy jest to problem klang z najnowszym gcc 4.7 libstC++?

+2

Jesteś jawnie '-I' gcc-4.7 wewnętrzne nagłówki w kompilacji 'clang'; Nie spodziewałbym się, że to będzie działać rozsądnie. – geekosaur

+0

jeśli to zrobię: widzę również błąd. @work: boostTest $ clang ++ -std = C++ 11 -L/opt/local/lib/gcc47 main.cpp -o główny main.cpp: 1: 10: błąd krytyczny: plik 'mutex' nie został odnaleziony # zawierają 1 błąd generowany. –

+3

Czy próbowałeś przekazać -std = C++ 11 -stdlib = libstdC++ –

Odpowiedz

8

Dlaczego mówisz -I/opt/local/include/gcc47/c++?

To nie powinno być konieczne z GCC lub Clang i nie będzie działać. Nie wszystkie nagłówki libstdC++ są w ramach tej ścieżki, istnieją pewne podstawowe nagłówki gdzie indziej, które określają takie rzeczy jak _GLIBCXX_BEGIN_NAMESPACE_VERSION

To nie powiedzie się z GCC ponieważ GCC już wie jak znaleźć inne nagłówki, więc jest to zbędne jawnie użyć -I i -L opcje. To nie działa z Clangiem, ponieważ mówisz tylko, jak znaleźć niektóre nagłówki, których potrzebuje, ale nie mówisz, jak znaleźć resztę.

Przestań próbować przesłonić standardowe ścieżki biblioteki kompilatora, niech używa wbudowanych ścieżek, o których już wie.

+0

Mam ten sam problem. Naszym problemem jest to, że Clang wykorzystuje system GCC dla swoich bibliotek i nagłówków. Chcemy użyć ** niezależnej ** instalacji GCC (tych z MacPorts) jako bazy Clanga. Jak powiedzieliśmy Clangowi, aby szukał gdzie indziej GCC, że kompilator, którego używa do "standardowych ścieżek biblioteki" jest * zły * ?! (Odpowiedzi na podobne zapytania, takie jak "install libC++" lub "hard-code the new path i recompile clang", byłyby tutaj bezużyteczne.) – CTMacUser

+2

@CTMacUser, Musisz przebudować klang, używając '--with-gcc- toolchain', aby powiedzieć, gdzie znaleźć nagłówki i biblioteki GCC. Możesz być w stanie zastąpić ścieżki dla istniejącej instalacji z bardzo ostrożnym użyciem wielu opcji '-I' i' -L', ale musisz zastąpić ** wszystkie ** odpowiednimi ścieżkami. Skompiluj z 'gcc -v', aby zobaczyć wszystkie standardowe katalogi wyszukiwania, których używa GCC, które również musisz poinformować o użyciu Klanga. Nawet wtedy może się nie udać (clang ma niektóre zakodowane ścieżki, które są ustawione podczas instalacji i nie wiem, czy można je przesłonić) –

+0

Myślę, że to jest właściwa odpowiedź. –

7

Używam clang-3.1 z gcc4.6 libstdC++ na FreeBSD 9.0/AMD64. Współpracuje z tych opcji:

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

Chyba Twój problem może być rozwiązany do korzystania z tych opcji:

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

Można użyć special option -gcc-toolchain, który jest domyślnie ustawiony przez --with-gcc-toolchain podczas kompilowania szczęk.To trochę łatwiej niż rekompilacji brzękiem, gdy chcesz użyć innej biblioteki GCC :)

tak:

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

Lub, w przypadku (wiem, że to 4 lat :)) wydaje się być

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

Folder "toolchain" powinien zawierać foldery "include" i "lib". Zarówno kompilator, jak i linker używają tej opcji. Uważaj: --gcc-toolchain nie jest poprawną opcją, użyj przedrostka jako przedrostka (mimo że llvm wiki stwierdza inaczej - zaznaczyłem go na pniu 3.8).

Powiązane problemy