在CodeLite（Windows）中将编译器从MinGW32更改为clang会导致编译错误 [英] Changing compiler from MinGW32 to clang in CodeLite (Windows) results in compilation errors
问题描述
我有一个项目使用MinGW32在Windows 8.1上使用CodeLite成功构建。我试图将编译器从MinGW32更改为clang。但是，在切换编译器后，我得到以下错误：
c：/MinGW/lib/gcc/mingw32/4.8。 1 / include / c ++ \bits / stringfwd.h：74：33：error：使用未声明的标识符'char16_t'
...其次是许多其他类似的性质。所以，我试着做一个更简单的程序来检查程序是否只是在我的代码，我很幸运与MinGW32。
以下程序也展示了同样的错误：
#include< iostream>
int main（int argc，char ** argv）
{
std :: cout< Hello World< std :: endl;
return 0;
}
在CodeLite中，设置了以下编译器选项）：
-g; -O0; -Wall; -std = c ++ 11
我也试过检查启用C ++ 11标准（clang）
在互联网上进行一些搜索后，我发现了以下问题：
因此，我尝试将 -fno-ms-compatibility 添加到我的编译器选项。这似乎有效果，因为编译器错误更改为：
c：/MinGW/lib/gcc/mingw32/4.8.1 /include/c++\bits/char_traits.h:391:7：error：can not mangle this built-in char16_t type yet
I尝试使用流行的搜索引擎找到一个解决方案，但我所能找到的是一个文件中的引用 MicrosoftMangle.cpp 。下面是提到我遇到的错误的部分：
void MicrosoftCXXNameMangler :: mangleType（const BuiltinType * T，
SourceRange Range）{
//< type> :: =< builtin-type>
//< builtin-type> :: = X＃void
// :: = C＃signed char
// :: = D＃char
// :: = E＃unsigned char
// :: = F＃short
// :: = G＃unsigned short（如果不是内置函数，则为wchar_t）
// :: = H＃int
// :: I ＃unsigned int
// :: = J＃long
// :: = K＃unsigned long
// L＃< none>
// :: = M＃float
// :: = N＃double
// :: = O＃long double（__float80不同）
//： ：= _J＃long long，__int64
// :: = _K＃unsigned long long，__int64
// :: = _L＃__int128
// :: = _M＃unsigned __int128
// :: = _N＃bool
// _O＃< parameter in parameter>
// :: = _T＃__float80（Intel）
// :: = _W＃wchar_t
// :: = _Z＃__float80（数字火星）
开关 - > getKind（））{
case BuiltinType :: Void：Out< 'X';打破;
case BuiltinType :: SChar：Out< 'C';打破;
case BuiltinType :: Char_U：case BuiltinType :: Char_S：Out< 'D';打破;
case BuiltinType :: UChar：Out<< 'E';打破;
case BuiltinType :: Short：Out<< 'F';打破;
case BuiltinType :: UShort：Out< 'G';打破;
case BuiltinType :: Int：Out< 'H';打破;
case BuiltinType :: UInt：Out< '一世';打破;
case BuiltinType :: Long：Out< 'J';打破;
case BuiltinType :: ULong：Out< 'K';打破;
case BuiltinType :: Float：Out< 'M';打破;
case BuiltinType :: Double：Out< 'N';打破;
// TODO：相应地确定尺寸和角度
case BuiltinType :: LongDouble：Out< 'O';打破;
case BuiltinType :: LongLong：Out< _J;打破;
case BuiltinType :: ULongLong：Out< _K;打破;
case BuiltinType :: Int128：Out<< _L;打破;
case BuiltinType :: UInt128：Out< _M;打破;
case BuiltinType :: Bool：Out< _N打破;
case BuiltinType :: WChar_S：
case BuiltinType :: WChar_U：Out< _W;打破;
#define BUILTIN_TYPE（Id，SingletonId）
#define PLACEHOLDER_TYPE（Id，SingletonId）\
case BuiltinType :: Id：
#includeclang / AST /BuiltinTypes.def
case BuiltinType :: Dependent：
llvm_unreachable（placeholder types should not get to name mangling）;
case BuiltinType :: ObjCId：Out< PAUobjc_object @@;打破;
case BuiltinType :: ObjCClass：Out< PAUobjc_class @@;打破;
case BuiltinType :: ObjCSel：Out< PAUobjc_selector @@;打破;
case BuiltinType :: OCLImage1d：Out<< PAUocl_image1d @@;打破;
case BuiltinType :: OCLImage1dArray：Out<< PAUocl_image1darray @@;打破;
case BuiltinType :: OCLImage1dBuffer：Out< PAUocl_image1dbuffer @@;打破;
case BuiltinType :: OCLImage2d：Out<< PAUocl_image2d @@;打破;
case BuiltinType :: OCLImage2dArray：Out< PAUocl_image2darray @@;打破;
case BuiltinType :: OCLImage3d：Out<< PAUocl_image3d @@;打破;
case BuiltinType :: OCLSampler：Out<< PAUocl_sampler @@;打破;
case BuiltinType :: OCLEvent：Out<< PAUocl_event @@;打破;
case BuiltinType :: NullPtr：Out< $$ T;打破;
case BuiltinType :: Char16：
case BuiltinType :: Char32：
case BuiltinType :: Half：{
DiagnosticsEngine& Diags = Context.getDiags（）;
unsigned DiagID = Diags.getCustomDiagID（DiagnosticsEngine :: Error，
can not mangle this built-in％0 type yet）;
Diags.Report（Range.getBegin（），DiagID）
<< T> getName（Context.getASTContext（）。getPrintingPolicy（））
<<范围;
break;
}
}
}
出来的想法如何解决我的问题，因此这个问题。预先感谢您能给我的任何帮助。
其他信息
我意识到我仍然在这里使用MinGW32包含目录，这是为了作为本教程的CodeLite 建议我这样做。
为了更简单：
我很确定clang未准备好进行Windows开发。
除了代码完成库，我还没有看到单个生产应用程序在MSW下成功编译clang。
注意，我确实设法构建一个简单的hello世界，但它运行它时失败了（特别是当涉及例外时）
长故事：坚持Windows的MinGW（gcc）将获得
这里是在我的机器上使用codelite构建一个简单的hello世界的输出（使用从LLVM网站下载的clang 3.4，并让codelite从settings-> build设置 - >自动检测编译器）：
C：\Windows \system32 \cmd.exe / c /MinGW-4.8.1/bin/mingw32-make.exe -j8 SHELL = cmd.exe -e -f Makefile
----------构建项目：[ClangHW - Debug] ----------
mingw32-make.exe [1]：输入目录'D：/ src / TestArea / ClangHW'
D：/ software / LLVM / bin / clang ++ .exe -cD：/src/TestArea/ClangHW/main.cpp-g -O0 -Wall -o ./Debug/main.cpp.o -Ic：/mingw-4.8.1/lib/gcc/mingw32 /4.8.1/include/c++ -Ic：/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include/c ++ / mingw32 -Ic：/mingw-4.8.1/lib/gcc/mingw32/4.8 .1 / include / c ++ / backward -Ic：/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include -Ic：/mingw-4.8.1/include -Ic：/mingw-4.8.1/ lib / gcc / mingw32 / 4.8.1 / include-fixed -I。 -一世。
D：/ software / LLVM / bin / clang ++。exe -o ./Debug/ClangHW @ClangHW.txt-L。
mingw32-make.exe [1]：离开目录'D：/ src / TestArea / ClangHW'
0错误，0警告
但是，当我运行它时会打印hello world消息并立即崩溃
注意，clang使用MinGW包含路径的原因很简单：它不带有自己的头文件，而是依赖于它们的存在（codelite使用你的默认MinGW编译器包含路径，并将它们用于clang） p>
总结：我强烈建议你坚持使用MinGW或VC
Eran（CodeLite IDE的作者） p>
I have a project the successfully builds using MinGW32 on Windows 8.1 using CodeLite. I am trying to change the compiler from MinGW32 to clang. However, after switching the compiler over I get the following error:
c:/MinGW/lib/gcc/mingw32/4.8.1/include/c++\bits/stringfwd.h:74:33: error: use of undeclared identifier 'char16_t'
...followed by many others of a similar nature. So, I tried making a simpler program to check if the program was simply in my code and I'd been 'lucky' with MinGW32.
The following program also exhibits the same error:
#include <iostream>
int main(int argc, char **argv)
{
std::cout << "Hello World" << std::endl;
return 0;
}
Within CodeLite, the following compiler options are set (these have not changed between compilers):
-g;-O0;-Wall;-std=c++11
I've also tried checking the Enable C++11 Standard (clang) box at the workspace level, just to be sure.
After some searching on the internet, I found the following issue:
Build fails on clang errors. #762
As a result of this, I tried adding -fno-ms-compatibility to my compiler options. This did seem to have an effect, as the compiler error changed to:
c:/MinGW/lib/gcc/mingw32/4.8.1/include/c++\bits/char_traits.h:391:7: error: cannot mangle this built-in char16_t type yet
I tried using a popular search engine to find a solution to this too, but all I could find was a reference to it inside a file called MicrosoftMangle.cpp. Here is the part which mentioned the error I encountered:
void MicrosoftCXXNameMangler::mangleType(const BuiltinType *T,
SourceRange Range) {
// <type> ::= <builtin-type>
// <builtin-type> ::= X # void
// ::= C # signed char
// ::= D # char
// ::= E # unsigned char
// ::= F # short
// ::= G # unsigned short (or wchar_t if it's not a builtin)
// ::= H # int
// ::= I # unsigned int
// ::= J # long
// ::= K # unsigned long
// L # <none>
// ::= M # float
// ::= N # double
// ::= O # long double (__float80 is mangled differently)
// ::= _J # long long, __int64
// ::= _K # unsigned long long, __int64
// ::= _L # __int128
// ::= _M # unsigned __int128
// ::= _N # bool
// _O # <array in parameter>
// ::= _T # __float80 (Intel)
// ::= _W # wchar_t
// ::= _Z # __float80 (Digital Mars)
switch (T->getKind()) {
case BuiltinType::Void: Out << 'X'; break;
case BuiltinType::SChar: Out << 'C'; break;
case BuiltinType::Char_U: case BuiltinType::Char_S: Out << 'D'; break;
case BuiltinType::UChar: Out << 'E'; break;
case BuiltinType::Short: Out << 'F'; break;
case BuiltinType::UShort: Out << 'G'; break;
case BuiltinType::Int: Out << 'H'; break;
case BuiltinType::UInt: Out << 'I'; break;
case BuiltinType::Long: Out << 'J'; break;
case BuiltinType::ULong: Out << 'K'; break;
case BuiltinType::Float: Out << 'M'; break;
case BuiltinType::Double: Out << 'N'; break;
// TODO: Determine size and mangle accordingly
case BuiltinType::LongDouble: Out << 'O'; break;
case BuiltinType::LongLong: Out << "_J"; break;
case BuiltinType::ULongLong: Out << "_K"; break;
case BuiltinType::Int128: Out << "_L"; break;
case BuiltinType::UInt128: Out << "_M"; break;
case BuiltinType::Bool: Out << "_N"; break;
case BuiltinType::WChar_S:
case BuiltinType::WChar_U: Out << "_W"; break;
#define BUILTIN_TYPE(Id, SingletonId)
#define PLACEHOLDER_TYPE(Id, SingletonId) \
case BuiltinType::Id:
#include "clang/AST/BuiltinTypes.def"
case BuiltinType::Dependent:
llvm_unreachable("placeholder types shouldn't get to name mangling");
case BuiltinType::ObjCId: Out << "PAUobjc_object@@"; break;
case BuiltinType::ObjCClass: Out << "PAUobjc_class@@"; break;
case BuiltinType::ObjCSel: Out << "PAUobjc_selector@@"; break;
case BuiltinType::OCLImage1d: Out << "PAUocl_image1d@@"; break;
case BuiltinType::OCLImage1dArray: Out << "PAUocl_image1darray@@"; break;
case BuiltinType::OCLImage1dBuffer: Out << "PAUocl_image1dbuffer@@"; break;
case BuiltinType::OCLImage2d: Out << "PAUocl_image2d@@"; break;
case BuiltinType::OCLImage2dArray: Out << "PAUocl_image2darray@@"; break;
case BuiltinType::OCLImage3d: Out << "PAUocl_image3d@@"; break;
case BuiltinType::OCLSampler: Out << "PAUocl_sampler@@"; break;
case BuiltinType::OCLEvent: Out << "PAUocl_event@@"; break;
case BuiltinType::NullPtr: Out << "$$T"; break;
case BuiltinType::Char16:
case BuiltinType::Char32:
case BuiltinType::Half: {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this built-in %0 type yet");
Diags.Report(Range.getBegin(), DiagID)
<< T->getName(Context.getASTContext().getPrintingPolicy())
<< Range;
break;
}
}
}
At this point, I am out of ideas on how to solve my problem, hence this question. Thank you in advance for any help you're able to give me!
Additional Information
I realise that I am still using the MinGW32 include directories here, and this in on purpose as this tutorial on CodeLite suggested I do so.
To make things simpler: I am pretty sure that clang is not ready for Windows development. Other than code completion library, I have not seen a single production application successfully compiled with clang under MSW.
Note that I did manage to build a simple hello world, but it failed miserably when running it (especially when exception are involved)
Long story short: stick to MinGW (gcc) for Windows, its the most reliable thing you will get
Here the output of building a simple hello world with codelite on my machine (using clang 3.4 downloaded from LLVM website, and letting codelite detect it from settings->build settings->auto detect compilers):
C:\Windows\system32\cmd.exe /c "C:/MinGW-4.8.1/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile"
"----------Building project:[ ClangHW - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/src/TestArea/ClangHW'
D:/software/LLVM/bin/clang++.exe -c "D:/src/TestArea/ClangHW/main.cpp" -g -O0 -Wall -o ./Debug/main.cpp.o -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include/c++ -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include/c++/mingw32 -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include/c++/backward -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include -Ic:/mingw-4.8.1/include -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include-fixed -I. -I.
D:/software/LLVM/bin/clang++.exe -o ./Debug/ClangHW @"ClangHW.txt" -L.
mingw32-make.exe[1]: Leaving directory 'D:/src/TestArea/ClangHW'
0 errors, 0 warnings
It compiles fine, however, when I run it - it prints the "hello world" message and crashes instantly
Note that the reason that clang is using MinGW include paths, is simple: it does not come with its own header files, instead it relies on their existence (codelite uses your "default" MinGW compiler include paths and uses them for clang)
To conclude: I strongly recommend you to stick to MinGW or VC
Eran (Author of CodeLite IDE)
这篇关于在CodeLite（Windows）中将编译器从MinGW32更改为clang会导致编译错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
