Prebuilt clang for Windows versions versus versions built with the latest source

If I look at pre-built version of clang for Windows I notice that there are no dependencies on any C++ implementation DLLs but only on the common lower level Windows DLLs kernel32.dll, shell32.dll, and advapi32.dll, which are all in the windows/system32 directory. This appears pretty nice.

If I build clang from source using some version of mingw-64/gcc as the compiler and CMake/Ninja as the build system I end up with a clang which has dependencies on the above mentioned lower level Windows DLLs and msvcrt.dll in the windows/system32 directory, as well as libstdc++6.dll and on whatever other DLL represents the exceptional model for that version of mingw-64/gcc in a mingw-64/gcc bin directory. If I build a 32-bit version of clang with mingw-64/gcc 32-bit supporting the dwarf exception model clang has a dependency on LIBGCC_S_DW2-1.DLL. If I build a 64-bit version of clang with mingw-64/gcc 64-bit supporting the seh exception model clang has a dependency on LIBGCC_S_SEH-1.DLL.

Why is there this discrepancy between the pre-built versions and the 32-bit and 64-bit versions of clang which I build ?

Or better yet, with what is the clang pre-built versions being built so that it has no dependencies on any compiler implementation DLL ?

Here’s the script +Hans uses to build so you can compare.

build_llvm_360.bat|attachment (2.32 KB)

Here's the script +Hans uses to build so you can compare.

This script suggests that it is building clang using Visual Studio 2012. But it is using Ninja as the CMake generator so I am confused by what is happening here. Can anybody clarify what is being used to build clang in the script being presented to me ?

Yes, you can use ninja with VC++, it just replaces MSBuild.

Yes, you can use ninja with VC++, it just replaces MSBuild.

Thanks ! Never realized that.

1) Building clang with VC++11 ( VS2012 ) has no dependencies on any compiler DLLs.
2) Building clang with mingw-64/gcc has dependencies on the libstdc++ DLL and whatever DLL represents the mingw-64/gcc exception model.

Why is this ?

I see these LLVM variablles in the build script:

LLVM_ENABLE_ASSERTIONS
LLVM_INSTALL_TOOLCHAIN_ONLY
LLVM_USE_CRT_RELEASE
LLVM_DEFAULT_TARGET_TRIPLE

There is no documentation on the 'Building LLVM with CMake' page ( http://llvm.org/docs/CMake.html page ) for the last three. Do any of these remove compiler DLL dependencies ? Seems doubtful.

Both MSVC and mingw should support static linking. Hans’s release script uses the /MT compiler flag to do it for MSVC. For mingw, you need to pass a flag like -static, -static-libstdc++, or -static-libgcc. I don’t use mingw so I couldn’t say which actually does the job.

Both MSVC and mingw should support static linking. Hans's release script
uses the /MT compiler flag to do it for MSVC. For mingw, you need to
pass a flag like -static, -static-libstdc++, or -static-libgcc. I don't
use mingw so I couldn't say which actually does the job.

Thanks, that explains it ! I assume the script does this via the 'LLVM_USE_CRT_RELEASE=MT' switch, but I couldn't find any documentation as to its meaning or use. I will try passing a compiler switch for static linking for mingw-64/gcc in the CMAKE_CXX_FLAGS switch once I figure out what the switch is.