找不到clang,找不到class 'predis\client' no

DevC++怎么加载llvm的clang？

如果你想在 Dev-C++ 中使用 LLVM 的 Clang 编译器，你需要手动安装 Clang。

首先，你需要从 LLVM 的网站下载 Clang 的最新版本。 你可以从这里下载：

然后，你需要将 Clang 安装在 Dev-C++ 可以找到的地方。 例如，你可以将 Clang 安装在 Dev-C++ 的安装目录中，或者你可以将 Clang 安装在系统的 PATH 环境变量所指的目录中。

最后，你需要在 Dev-C++ 中配置编译器。 在 Dev-C++ 中打开“工具”菜单，然后选择“编译器选项”。 在“编译器”选项卡中，你可以找到“C++ 编译器”选项。 使用浏览按钮找到 Clang 的可执行文件，然后点击“确定”按钮保存更改。

现在，你应该能够在 Dev-C++ 中使用 Clang 编译 C++ 代码了。

[VScode]关于找不到头文件的解决

在非工作区使用c或c++出现这个问题，属于正常现象，请自行检查工作区的设置

查看是否将使用到的头文件目录都放到了 c_cpp_properties.json 中的 includePath 里面去了

然后把所有目录全部添加到 c_cpp_properties.json 中的 includePath 里面

可以检查下 c_cpp_properties.json 中 compilerPath 路径是否完整，请精确到 gcc.exe

需注意Linux系统下路径为 /usr/bin/gcc

可检查下系统的环境变量，是否 clang.exe 所在的文件夹添加到了 Path 环境变量中，确实是否有其他额外的编译器，添加到了Path变量里面

clang编译器不能找到stdio.h

使用尖括号的话，编译时会先在系统include目录里搜索，如果找不到才会在源代码所在目录搜索；使用双引号则相反，会先在源代码目录里搜索。这就意味着，当系统里（如/usr/include/里）有一个叫做math.h的头文件，而你的源代码目录里也有一个你自己写的math.h头文件，那么使用尖括号时用的就是系统里的；而使用双引号的话则会使用你自己写的那个。 所以建议： 使用系统里提供的头文件时使用尖括号 使用自己编写的头文件时使用双引号

百度一下“酷影模式” 你懂得

clang 编译不过去这个是什么原因

1，Buildllvm/clang/lldb/lld3.5.0等组件1.0准备：至少需要从llvm.org下载llvm,cfe,lldb,compiler-rt,lld等3.5.0版本的代码。$tarxfllvm-3.5.0.src.tar.gz$cdllvm-3.5.0.src$mkdir-ptools/clang$mkdir-ptools/clang/tools/extra$mkdir-ptools/lld$mkdir-pprojects/compiler-rt$tarxfcfe-3.5.0.src.tar.xz-Ctools/clang--strip-components=1$tarxfcompiler-rt-3.5.0.src.tar.xz-Cprojects/compiler-rt--strip-components=1$tarxflldb-3.5.0.src.tar.xz-Ctools/clang/tools/extra--strip-components=1$tarxflld-3.5.0.src.tar.xz-Ctools/lld--strip-components=11.1【可选】使用clang--stdlib=libc++时，自动添加-lc++abi。libc++组件可以使用gcclibstdc++的supc++ABI，也可以使用c++abi，cxxrt等，实际上自动添加-lc++abi是不必要的，这里这么处理，主要是为了方便起见。实际上完全可以在“clang++-stdlib=libc++”时再手工添加-lc++abi给链接器。这里涉及到链接时DSO隐式还是显式的问题，早些时候ld在链接库时会自动引入由库引入的依赖动态库，后来因为这个行为的不可控性，所以ld链接器的行为做了修改，需要显式的写明所有需要链接的动态库，才会有手工添加-lc++abi这种情况出现。---llvm-3.0.src/tools/clang/lib/Driver/ToolChain.cpp2012-03-2618:49:06.663029075+0800+++llvm-3.0.srcn/tools/clang/lib/Driver/ToolChain.cpp2012-03-2619:36:04.260071355+0800@@-251,6+251,7@@switch(Type){caseToolChain::CST_Libcxx:CmdArgs.push_back("-lc++");+CmdArgs.push_back("-lc++abi");break;caseToolChain::CST_Libstdcxx:1.2【必要】给clang++添加-fnolibgcc开关。这个开关主要用来控制是否连接到libgcc或者libunwind。注：libgcc不等于libunwind。libgcc_eh以及supc++的一部分跟libunwind功能相当。注：libgcc_s和compiler_rt的一部分相当。这个补丁是必要的，不会对clang的正常使用造成任何影响，只有在使用“-fnolibgcc"参数时才会起作用。之所以进行了很多unwind的引入，主要是为了避免不必要的符号缺失麻烦，这里的处理相对来说是干净的，通过as-needed规避了不必要的引入。---llvm-static-3.5.0.bak/tools/clang/lib/Driver/Tools.cpp2014-09-1013:46:02.581543888+0800+++llvm-static-3.5.0/tools/clang/lib/Driver/Tools.cpp2014-09-1016:03:37.559019321+0800@@-2060,9+2060,15@@".a");CmdArgs.push_back(Args.MakeArgString(LibClangRT));-CmdArgs.push_back("-lgcc_s");-if(TC.getDriver().CCCIsCXX())-CmdArgs.push_back("-lgcc_eh");+if(Args.hasArg(options::OPT_fnolibgcc)){+CmdArgs.push_back("--as-needed");+CmdArgs.push_back("-lunwind");+CmdArgs.push_back("--no-as-needed");+}else{+CmdArgs.push_back("-lgcc_s");+if(TC.getDriver().CCCIsCXX())+CmdArgs.push_back("-lgcc_eh");+}}staticvoidaddProfileRT(@@-7150,24+7156,50@@boolisAndroid=Triple.getEnvironment()==llvm::Triple::Android;boolStaticLibgcc=Args.hasArg(options::OPT_static_libgcc)||Args.hasArg(options::OPT_static);+++if(!D.CCCIsCXX())-CmdArgs.push_back("-lgcc");+if(Args.hasArg(options::OPT_fnolibgcc)){+CmdArgs.push_back("--as-needed");+CmdArgs.push_back("-lunwind");+CmdArgs.push_back("--no-as-needed");+}else+CmdArgs.push_back("-lgcc");if(StaticLibgcc||isAndroid){if(D.CCCIsCXX())-CmdArgs.push_back("-lgcc");+if(Args.hasArg(options::OPT_fnolibgcc)){+CmdArgs.push_back("--as-needed");+CmdArgs.push_back("-lunwind");+CmdArgs.push_back("--no-as-needed");+}else+CmdArgs.push_back("-lgcc");}else{if(!D.CCCIsCXX())CmdArgs.push_back("--as-needed");-CmdArgs.push_back("-lgcc_s");+if(Args.hasArg(options::OPT_fnolibgcc))+CmdArgs.push_back("-lunwind");+else+CmdArgs.push_back("-lgcc_s");if(!D.CCCIsCXX())CmdArgs.push_back("--no-as-needed");}if(StaticLibgcc!isAndroid)-CmdArgs.push_back("-lgcc_eh");+if(Args.hasArg(options::OPT_fnolibgcc)){+CmdArgs.push_back("--as-needed");+CmdArgs.push_back("-lunwind");+CmdArgs.push_back("--no-as-needed");+}else+CmdArgs.push_back("-lgcc_eh");elseif(!Args.hasArg(options::OPT_shared)D.CCCIsCXX())-CmdArgs.push_back("-lgcc");+if(Args.hasArg(options::OPT_fnolibgcc)){+CmdArgs.push_back("--as-needed");+CmdArgs.push_back("-lunwind");+CmdArgs.push_back("--no-as-needed");+}else+CmdArgs.push_back("-lgcc");//AccordingtoAndroidABI,wehavetolinkwithlibdlifweare//linkingwithnon-staticlibgcc.---llvm-static-3.5.0.bak/tools/clang/include/clang/Driver/Options.td2014-08-0712:51:51.000000000+0800+++llvm-static-3.5.0/tools/clang/include/clang/Driver/Options.td2014-09-1013:36:34.598511176+0800@@-788,6+788,7@@deffomit_frame_pointer:Flag,Group;deffopenmp:Flag,Group,Flags;deffopenmp_EQ:Joined,Group,Flags;+deffnolibgcc:Flag,Group,Flags;deffno_optimize_sibling_calls:Flag,Group;deffoptimize_sibling_calls:Flag,Group;defforce__cpusubtype__ALL:Flag;1.3llvm的其他补丁。llvm/clang将gcctoolchain的路径hardcode在代码中，请查阅tools/clang/lib/Driver/ToolChains.cpp。找到x86_64-redhat-linux之类的字符串。如果没有你系统特有的gcctripplestring，请自行添加。这个tripplestring主要是给llvm/clang搜索gcc头文件等使用的，不影响本文要构建的toolchain1.4构建clang/llvm/lldb本文使用ninja。顺便说一下，llvm支持configure和cmake两种构建方式。可能是因为工程太大，这两种构建方式的工程文件都有各种缺陷（主要表现在开关选项上，比如configure有，但是cmake却没有等）。llvm-3.4.1就是因为cmake工程文件的错误而导致了3.4.2版本的发布。综合而言，cmake+ninja的方式是目前最快的构建方式之一，可以将构建时间缩短一半以上。mkdirbuildcdbuildcmake\-GNinja\-DCMAKE_INSTALL_PREFIX=/usr\-DCMAKE_BUILD_TYPE="Release"\-DCMAKE_CXX_FLAGS="-std=c++11"\-DBUILD_SHARED_LIBS=OFF\-DLLVM_ENABLE_PIC=ON\-DLLVM_TARGETS_TO_BUILD="all"\-DCLANG_VENDOR="MyOS"..ninjaninjainstall如果系统原来就有clang/clang++的可用版本，可以添加：-DCMAKE_C_COMPILER=clang\-DCMAKE_CXX_COMPILER=clang++\这样就会使用系统的clang++来构建llvm/clang2，测试clang/clang++。自己找几个简单的c/cpp/objc等编译测试一下即可。完整测试可以在构建时作ninjacheck-all3，libunwind/libc++/libc++abi，一套不依赖libgcc,libstdc++的c++运行库。3.1从/pathscale/libunwind获取代码。libunwind有很多个实现，比如gnu的libunwind,path64的libunwind，还有libcxxabi自带的Unwinder.这里作下说明：1)，gnu的libunwind会有符号缺失和冲突。2)，libcxxabi自带的Unwinder是给mac和ios用的，也就是只能在darwin体系构建。目前Linux的实现仍然不全，等linux实现完整了或许就不再需要path64的unwind实现了。暂时建议使用pathscale的unwind实现。mkdir-pbuildcdbuildcmake-GNinja-DCMAKE_C_COMPILER=clang-DCMAKE_C_FLAGS="-m64"..ninjamkdir-p/usr/libcpsrc/libunwind.so/usr/libcpsrc/libunwind.a/usr/lib3.2第一次构建libcxx.必须先构建一次libcxx，以便后面构建libcxxabi。这里构建的libcxx实际上是使用gcc的libgcc/stdc++/supc++的。打上这个补丁来禁止libgcc的引入：diff-Nurlibcxx/cmake/config-ix.cmakelibcxxn/cmake/config-ix.cmake---libcxx/cmake/config-ix.cmake2014-06-2506:57:50.000000000+0800+++libcxxn/cmake/config-ix.cmake2014-06-2509:05:24.980350544+0800@@-28,5+28,4@@check_library_exists(cprintf""LIBCXX_HAS_C_LIB)check_library_exists(mccos""LIBCXX_HAS_M_LIB)check_library_exists(rtclock_gettime""LIBCXX_HAS_RT_LIB)-check_library_exists(gcc_s__gcc_personality_v0""LIBCXX_HAS_GCC_S_LIB)编译安装：mkdirbuildcdbuildcmake\-GNinja\-DCMAKE_INSTALL_PREFIX=/usr\-DCMAKE_C_COMPILER=clang\-DCMAKE_CXX_COMPILER=clang++\..ninjaninjainstall3.3，测试第一次构建的libcxx。使用"clang++-stdlib=libc++-otesttest.cpp-lstdc++"编译简单c++代码，检查是否出错。(如果前面构建clang是已经apply了c++abi的链接补丁，这里会出现找不到c++abi的情况，跳过即可)使用"lddtest"查看test二进制动态库使用情况。可以发现，test依赖于libgcc_s/libc++/libstdc++。（多少有些不爽了吧？使用了libc++居然还要依赖libstdc++？）

谁给说说clang找不到c++头文件怎么解决

啊？我没弄懂你的意思，我只是想用clang来编译C++,他们这个上面有clang的C/C++的标准库文件，然后现在我的clang能编译C++，但是C++的标准库要编译，我就是编译他们这个标准库文件的时候，编译器报错说找不到string.h这个文件