Lors de l'activation de C++11 avec stdlibc++ 4.7, clang erreur, alors que gcc compile fine

J'ai essayé d'obtenir de C++11 au travail, après la navigation sur différents sites web et de Q/r, je suis toujours avoir des problèmes avec. Je veux utiliser clang avec libstdc++. Il est indiqué dans le cliquetis d'état qu'il est pris en charge avec patch - http://clang.llvm.org/libstdc++4.7-clang11.patch. J'ai télécharger le gcc4.7 de macports et fait des changements correspondants dans les en-têtes pour gcc4.7

La raison pour laquelle je n'utilise pas la libc++ est parce que ABI compatibilités entre libc++ ou libstdc++, indiqué par ce fil: Pourquoi ne peut-clang avec la libc++ en c++0x lien mode de ce coup de pouce::program_options exemple?

OK, après tout est fait, j'ai testé mon programme d'installation avec le code suivant:

#include <mutex>
#include <thread>

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

Je m'attends à ce que devrait inclure le travail en vertu de c++11.

Donc, voici comment je le compiler avec:
avec GCC

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

Compiler avec succès

avec Clang

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

J'obtiens cette erreur:

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

Je suis en utilisant 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

Je fais quelque chose de mal? ou est-ce un clang problème avec la dernière version de gcc 4.7 libstc++?

Vous êtes explicitement -I-ing gcc-4.7-têtes internes dans un clang compiler, je ne m'attends pas à ce travail de discernement.
si je fais cela: j'ai aussi voir l'erreur. @work:boostTest$ clang++ -std=c++11 -L/opt/local/lib/gcc47 main.cpp -o principal.cpp:1:10: erreur fatale: mutex " fichier non trouvé #include <mutex> 1 erreur générée.
Avez-vous essayé en passant -std=c++11 -stdlib=libstdc++
juste essayé, il produit les mêmes résultats.
Quel système d'exploitation utilisez-vous ? Sur la plupart des Systèmes d'exploitation de Clang devriez être capable de trouver automatiquement la GCC en-têtes. Si ce n'est pas pour votre système d'exploitation, alors le pilote de la logique devrait être adapté.

OriginalL'auteur Negative Zero | 2012-04-25

  1. 8

    Pourquoi dis-tu -I/opt/local/include/gcc47/c++ ?

    Qui ne devrait pas être nécessaire, soit avec GCC ou Clang, et ne fonctionnera pas. Pas tous les libstdc++ - têtes sont en vertu de ce chemin, il y a quelques essentielle en-têtes ailleurs qui définissent des choses comme _GLIBCXX_BEGIN_NAMESPACE_VERSION

    Il ne s'agit pas avec GCC car GCC sait déjà comment trouver les autres en-têtes, il est donc inutile de les utiliser de manière explicite -I et -L options. Il ne fonctionne pas avec Clang parce que vous êtes seulement pour lui dire comment trouver les en-têtes de elle a besoin, mais ne pas lui dire comment trouver le reste.

    Arrêter d'essayer de remplacer le compilateur standard de la bibliothèque des chemins, de la laisser utiliser les chemins qu'il connaît déjà.

    J'ai le même problème. Notre problème est que Clang utilise le système de la GCC pour ses bibliothèques et en-têtes. Nous voulons utiliser un indépendant l'installation de GCC (ceux de MacPorts) Clang de base. Comment pouvons-nous dire Clang chercher ailleurs pour GCC, le compilateur c'est à l'aide de la "norme de la bibliothèque des chemins" est mal?! (Réponses à des requêtes similaires, tels que "installer libc++" ou "coder en dur le nouveau chemin d'accès et de recompiler clang," serait inutile ici).
    Vous avez besoin de reconstruire grand bruit de ferraille, à l'aide de --with-gcc-toolchain à lui dire où trouver de la GCC en-têtes et les bibliothèques. Vous être en mesure de remplacer les chemins d'accès pour votre installation existante avec très attention à l'utilisation de beaucoup de -I et -L options, mais vous devez remplacer tous les chemins concernés. Compiler avec gcc -v pour voir tous les répertoires de recherche de GCC utilise, vous auriez également besoin de dire Clang à utiliser. Même alors, il ne pourrait pas travailler (clang a certains chemins codés en dur qui sont définies lors de l'installer et je ne sais pas si elles peuvent être remplacées)
    Je pense que c'est la bonne réponse.
    Serait définissant la variable d'environnement CPLUS_INCLUDE_PATH (et CPATH) ne fonctionne plus (au lieu de reconstruire clang)?
    non, sauf si vous aussi remplacer sa bibliothèque des chemins. Elle aurait aussi le même problème que l'utilisation de -I/opt/local/include/gcc47/c++, c'est à dire pas tous les en-têtes sont dans ce répertoire, alors vous devez savoir que tous les répertoires nécessaires et assurez-vous de leur fournir tous les dans le bon ordre.

    OriginalL'auteur Jonathan Wakely

  2. 7

    Je suis en utilisant clang-3.1 avec gcc4.6 libstdc++ sur FreeBSD 9.0/AMD64. Il fonctionne avec ces 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

    Je suppose que ton problème peut être résolu à l'utilisation de ces options:

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

    OriginalL'auteur Yasuhiro Fujii

  3. 0

    Vous pouvez utiliser le l'option -gcc-toolchain, qui est implicitement défini par --with-gcc-toolchain lorsque vous compilez clang. C'est un peu plus facile que de recompiler clang lorsque vous souhaitez utiliser un autre GCC bibliothèques 🙂

    Comme ça:

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

    Ou, dans votre cas (je sais que c'est 4 ans :)) il semble être

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

    La 'chaîne' dossier doit contenir "include" et " lib " dossiers. Les deux compilateur et l'éditeur de liens d'utiliser cette option. Attention: --gcc-toolchain n'est pas une option valide, utilisez un tiret comme le préfixe (même si le llvm wiki en dispose autrement — je l'ai vérifié sur clang 3.8 tronc).

    OriginalL'auteur gluk47