gpt4 book ai didi

c++ - 将编译器从 MinGW32 更改为 CodeLite (Windows) 中的 clang 会导致编译错误

转载 作者:搜寻专家 更新时间:2023-10-31 00:34:54 24 4
gpt4 key购买 nike

我有一个使用 CodeLite 在 Windows 8.1 上使用 MinGW32 成功构建的项目。我正在尝试将编译器从 MinGW32 更改为 clang。但是,在切换编译器之后,出现以下错误:

c:/MinGW/lib/gcc/mingw32/4.8.1/include/c++\bits/stringfwd.h:74:33: error: use of undeclared identifier '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

我还尝试在工作区级别选中 Enable C++11 Standard (clang) 框,以确保万无一失。

在网上搜索了一下,发现了以下问题:

Build fails on clang errors. #762

因此,我尝试将 -fno-ms-compatibility 添加到我的编译器选项中。这似乎确实有影响,因为编译器错误更改为:

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

我也尝试使用一个流行的搜索引擎来寻找解决方案,但我只能在名为 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 (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;
}
}
}

在这一点上,我不知道如何解决我的问题,因此提出了这个问题。预先感谢您能给我的任何帮助!

附加信息

我意识到我仍然在这里使用 MinGW32 包含目录,这是故意的 this tutorial on CodeLite建议我这样做。

最佳答案

为了让事情更简单:我很确定 clang 还没有为 Windows 开发做好准备。除了代码完成库,我还没有看到在 MSW 下使用 clang 成功编译的单个生产应用程序。

请注意,我确实设法构建了一个简单的 hello world,但在运行时却惨遭失败(尤其是在涉及异常时)

长话短说:坚持使用适用于 Windows 的 MinGW (gcc),这是您将获得的最可靠的东西

这里是在我的机器上使用 codelite 构建一个简单的 hello world 的输出(使用从 LLVM 网站下载的 clang 3.4,并让 codelite 从设置->build设置->自动检测编译器检测它):

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

它编译得很好,但是,当我运行它时 - 它会打印“hello world”消息并立即崩溃

请注意,clang 使用 MinGW 包含路径的原因很简单:它没有自己的头文件,而是依赖于它们的存在(codelite 使用您的“默认”MinGW 编译器包含路径并将它们用于 clang )

总结:我强烈建议你坚持使用 MinGW 或 VC

Eran(CodeLite IDE 的作者)

关于c++ - 将编译器从 MinGW32 更改为 CodeLite (Windows) 中的 clang 会导致编译错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25170594/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com