是。我有一个相当大的窗口（基于MFC）的项目，在其中我使用本机MSVC编译器来构建实际使用任何MFC（或其他Winapi）代码的所有组件，但将Clang-Cl用于一个特定的“核心”模块（作为静态库构建）。该核心模块中的所有代码均为严格符合标准符合条件（目前C ++ 17，但 vide infra ）。我多年来一直使用这种MSVC+Clang组合，尚未遇到与ABI不兼容有关的任何问题。 （但请注意，Windows上的静态库具有“ .lib”扩展名，而不是“ .a”。）
Specifically, can a static library (.a) compiled with clang be consumed by the MSVC toolchain? (ie. symbol definitions are not dllexport/imported).
Yes. I have a fairly large Windows (MFC-based) project in which I use the native MSVC compiler to build all components that actually use any MFC (or other WinAPI) code, but use clang-cl for one particular "core" module (built as a static library). All code in that core module is strictly Standard-compliant (C++17, currently, but vide infra). I have been using this MSVC+clang combination for some years and have yet to experience any issues related to ABI incompatibility. (But note that static libraries on Windows have the ".lib" extension, not ".a".)
Are binaries emitted by clang ABI compatible with binaries emitted by cl, up to and including the latest language standard?
Yes – but you'll need VS 2022 for C++20 or later: The clang-cl compiler (V11) that comes with VS 2019 only recognizes up to (and including) C++17; however, clang-cl V13 (as installed by VS 2022) can be set to use C++20 or C++23. (Also note that the library I mentioned above makes heavy use of the "STL" containers, like std::vector.)
Can clang emit 32-bit binaries?
Yes. Switching between 64-bit and 32-bit target architectures within the VS IDE works equally well for both MSVC and clang-cl projects. This also seems to work when switching to ARM64 targets (assuming you have installed the required tools), but I can't verify the final output, as I don't have access to an ARM64-based Windows system.
I recognise clang-cl is simply a driver for clang, but are there any practical limitations or other reasons not to favour clang-cl over cl for new projects?
I have tried building my entire project with the clang-cl tools but – so far – without success. This may be due to the fact that I am using MFC (I get a whole chunk of duplicate and/or missing symbols at link time). However, building simple, console-mode programs for Windows with clang-cl works just fine.
And, one further note: The run-time performance of my final program is considerably greater (i.e. faster) when compiling that core library with clang-cl, compared to the same code compiled with MSVC.
It was very misinterpretative that you called the compiler clang. Your ment clang-cl.exe, not clang, because clang demangle g++ cpmpatible, clang-cl.exe demangle msvc compatible. If you had put into a compile example, maybe : cmake -G Ninja -DCMAKE_C_COMPILER="clang-cl.exe" -DCMAKE_CXX_COMPILER="clang-cl.exe" -DCMAKE_BUILD_TYPE=Release -DCMAKE_LINKER="llvm-link.exe" . everyone would have understoodd it immediately (so do I now). In Inforamtion theory one example explains more than text only (I'm a mathematician and in math the theory is the meat in informations theory the examples - code snipped - are the meat). The compiler options from clang-cl.exe are exactly the options from msvc, but the option from clang are totally different (g++ options). Hopefully it helps the next reader to understand immediately, that clang-cl.exe is ment, not clang.
发布评论
评论（2）
是。我有一个相当大的窗口（基于MFC）的项目，在其中我使用本机MSVC编译器来构建实际使用任何MFC（或其他Winapi）代码的所有组件，但将Clang-Cl用于一个特定的“核心”模块（作为静态库构建）。该核心模块中的所有代码均为严格符合标准符合条件（目前C ++ 17，但 vide infra ）。我多年来一直使用这种MSVC+Clang组合，尚未遇到与ABI不兼容有关的任何问题。 （但请注意，Windows上的静态库具有“ .lib”扩展名，而不是“ .a”。）
吗 ？ VS 2019随附的编译器（V11）仅承认（包括）C ++ 17；但是，可以将Clang-CL V13（由VS 2022安装）设置为使用C ++ 20或C ++ 23。 （还请注意，我上面提到的库会使重使用“ stl”容器，例如
std :: vector。）。是。与MSVC和Clang-Cl项目之间的64位和32位目标体系结构之间的切换在同样效果。切换到ARM64目标时（假设您已经安装了所需的工具），这也似乎可以工作，但是我无法验证最终输出，因为我无法访问基于ARM64的Windows Windows系统。
我尝试使用Clang-Cl工具构建我的整个整个项目，但是 - 到目前为止 - 没有成功。此可能是由于我正在使用MFC（在链接时间我会得到一大笔化和/或丢失的符号）。但是，使用Clang-Cl的Windows构建简单的控制台模式程序效果很好。
而且，另一个注意事项：与使用MSVC编译的同一代码相比，我的最终程序的运行时间性能更大（即更快）。
Yes. I have a fairly large Windows (MFC-based) project in which I use the native MSVC compiler to build all components that actually use any MFC (or other WinAPI) code, but use clang-cl for one particular "core" module (built as a static library). All code in that core module is strictly Standard-compliant (C++17, currently, but vide infra). I have been using this MSVC+clang combination for some years and have yet to experience any issues related to ABI incompatibility. (But note that static libraries on Windows have the ".lib" extension, not ".a".)
Yes – but you'll need VS 2022 for C++20 or later: The clang-cl compiler (V11) that comes with VS 2019 only recognizes up to (and including) C++17; however, clang-cl V13 (as installed by VS 2022) can be set to use C++20 or C++23. (Also note that the library I mentioned above makes heavy use of the "STL" containers, like
std::vector.)Yes. Switching between 64-bit and 32-bit target architectures within the VS IDE works equally well for both MSVC and clang-cl projects. This also seems to work when switching to ARM64 targets (assuming you have installed the required tools), but I can't verify the final output, as I don't have access to an ARM64-based Windows system.
I have tried building my entire project with the clang-cl tools but – so far – without success. This may be due to the fact that I am using MFC (I get a whole chunk of duplicate and/or missing symbols at link time). However, building simple, console-mode programs for Windows with clang-cl works just fine.
And, one further note: The run-time performance of my final program is considerably greater (i.e. faster) when compiling that core library with clang-cl, compared to the same code compiled with MSVC.
您称为编译器案例是非常误解的。您的clang-cl.exe，而不是叮当声，因为clang demangle g ++ cpmpmatiby，clang-cl.exe emangle msvc兼容。如果您放入一个编译示例中，也许是：cmake -g ninja -dcmake_c_compiler =“ clang -cl.exe” -dcmake_cxx_compiler =“ clang -cl.exe” -dcmake_build_type = presention -dcmake_build_type = reparess -dcmake_link_linker =“
每个人都会立即理解它（我现在也是如此）。在Inforamtion理论中，一个示例不仅解释了文本（我是数学家，而且在数学中，理论是信息理论中的肉类 - 示例 - 代码剪切 - 是肉）。 Clang-cl.exe的编译器选项正是来自MSVC的选项，但是Clang的选项完全不同（G ++选项）。希望它可以帮助下一个读者立即理解，clang-cl.exe是指而不是clang。
It was very misinterpretative that you called the compiler clang. Your ment clang-cl.exe, not clang, because clang demangle g++ cpmpatible, clang-cl.exe demangle msvc compatible. If you had put into a compile example, maybe : cmake -G Ninja -DCMAKE_C_COMPILER="clang-cl.exe" -DCMAKE_CXX_COMPILER="clang-cl.exe" -DCMAKE_BUILD_TYPE=Release -DCMAKE_LINKER="llvm-link.exe" .
everyone would have understoodd it immediately (so do I now). In Inforamtion theory one example explains more than text only (I'm a mathematician and in math the theory is the meat in informations theory the examples - code snipped - are the meat). The compiler options from clang-cl.exe are exactly the options from msvc, but the option from clang are totally different (g++ options). Hopefully it helps the next reader to understand immediately, that clang-cl.exe is ment, not clang.