Building a Release build created a Debug build

Beginners
1

I am trying to make a release build of LLVM for the compiler I’m working on, however I can only get a debug build. I’ve had this issue with older versions of LLVM as well (I believe it was 18). I’m building with just CMake, no Ninja. Am I doing something wrong? Thanks in advance.

Architecture: x86_64

OS: Windows 10

CPU: Intel 9th Gen - 6 Cores (12 Threads)

Memory: 32GB

Version of LLVM: 20.1.8 (specific fork: GitHub - PCIT-Project/llvm-project: PCIT Project fork of LLVM (20.1.8). The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.)

Build Script:

cmake "../llvm-project/llvm" ^
		-G "Visual Studio 17 2022" ^
		-DCMAKE_INSTALL_PREFIX="../llvm-project/llvm/build-output" ^
		-DCMAKE_BUILD_TYPE=Release ^
		-DCMAKE_MSCV_RUNTIME_LIBRARY=MultiThreaded ^
		-DLLVM_ENABLE_PROJECTS="lld;clang" ^
		-DLLVM_TARGETS_TO_BUILD="AArch64;RISCV;WebAssembly;X86" ^
		-DLLVM_BUILD_TOOLS=OFF ^
		-DLLVM_ENABLE_ASSERTIONS=OFF ^
		-DLLVM_ENABLE_BINDINGS=OFF ^
		-DLLVM_ENABLE_EH=OFF ^
		-DLLVM_ENABLE_UNWIND_TABLES=OFF ^
		-DLLVM_INCLUDE_BENCHMARKS=OFF ^
		-DLLVM_INCLUDE_EXAMPLES=OFF

cmake --build . --target install

(actual build script can be found here: llvm-project-build/build_llvm.windows.bat at main · PCIT-Project/llvm-project-build · GitHub)

2

The cmake options look OK at first glance. What specifically are you seeing resulting binaries that you don’t think should be there?

3

The binaries have asserts, debug info, use the debug CRT, and are incredibly slow.

4

Probably the best thing would be to look at this: llvm-project/llvm/utils/release/build_llvm_release.bat at main · llvm/llvm-project · GitHub - that is used to build the Windows releases of LLVM. You can perhaps just use that script as-is for your release, or use it as an inspiration.

Also, I don’t recommend using the Visual Studio target for building; the “recommended” usage is to have two cmake build folders: one for creating the .sln and browsing the code in Visual Studio, and a second one to actually build with Ninja (cmake -GNinja …)

5

That typo might be an issue - it would default to the debug build I suspect.

6

I noticed the typo too. I tried fixing it and I got the same issue as before (debug build instead of release build).

I did what @aganea suggested and worked on slowly modifying the official release script. So far I’ve got this:

cmake -GNinja ^
	-DCMAKE_BUILD_TYPE=Release ^
	-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded ^
	-DLLVM_INSTALL_TOOLCHAIN_ONLY=ON ^
	-DLLVM_TARGETS_TO_BUILD="AArch64;RISCV;WebAssembly;X86" ^
	-DPython3_FIND_REGISTRY=NEVER ^
	-DPACKAGE_VERSION=%package_version% ^
	-DLLVM_ENABLE_PROJECTS="clang;lld" ^
	-DCOMPILER_RT_BUILD_ORC=OFF ^
	-DLLVM_BUILD_TOOLS=OFF ^
	-DLLVM_ENABLE_ASSERTIONS=OFF ^
	-DLLVM_ENABLE_BINDINGS=OFF ^
	-DLLVM_ENABLE_EH=OFF ^
	-DLLVM_ENABLE_UNWIND_TABLES=OFF ^
	-DLLVM_INCLUDE_BENCHMARKS=OFF ^
	-DLLVM_INCLUDE_EXAMPLES=OFF ^
	-DCLANG_DEFAULT_LINKER=lld ^
	-DLLVM_TARGETS_TO_BUILD="AArch64;RISCV;WebAssembly;X86" ^
	%llvm_src%\llvm	|| exit /b 1

ninja || ninja || ninja || exit /b 1

This script does successfully make a release build. However, I’m now running into a new issue - when I try to link the clang libs with my project, I get the following error (plus 111 other variations of the same issue):

unresolved external symbol "__declspec(dllimport) public: class clang::Expr * __cdecl clang::WorkGroupSizeHintAttr::getZDim(void)const " (__imp_?getZDim@WorkGroupSizeHintAttr@clang@@QEBAPEAVExpr@2@XZ)

I couldn’t find any reference to this on the internet. I was able to track down that this is generated in clang/AST/Attrs.inc. I can’t figure out what to link against to fix this issue - I’ve tried every lib with “clang” in the name that I can find.

(Note: I don’t have this issue when linking against the output of the debug build output from the script in my initial post)

7

You are using clang as a DLL it appears from the error, but the Windows DLL builds are experimental currently. You will need to fix these issues or can stick to static linking for the time being.

8

I don’t think I built the DLL build. I’m currently copying all of the .lib files from build_amd64_stage0/lib into my project - there are also no .dll files in that directory. The only .dll files I can find in the entire build are:

  • build_amd64_stage0/bin/libclang.dll
  • build_amd64_stage0/bin/LLVM-C.dll
  • build_amd64_stage0/bin/LTO.dll
  • build_amd64_stage0/bin/Remarks.dll

I did try and link against libclang as well, but that didn’t help.

9

I think that there is a mismatch between the build and the use - one side is built for static linking, the other side for dynamic.

10

I’m not entirely sure I understand what you’re saying, but I think you misunderstand what’s happening. Hopefully I can add more information.

As far as I am aware, I built the static build of LLVM and am statically linking against the .lib files. If I stop linking against any of the other .lib files that are required by my project for linking against the debug build (built by the script in the initial post (which compiles successfully)), linking errors for the symbols in that file occur, but those symbols do not list a __declspec(dllimport) as part of the signature (all of the ones I can’t fix, do).
The only symbols that are missing are seemingly ones generated in clang/AST/Attrs.inc (all of them I see are methods of classes all named some variation of XxxXxxAttr. All of these have the macro CLANG_API as part of the declaration. In the headers I’m using, the only use of CLANG_API is 443 times in clang/AST/Attrs.inc, twice in clang\astmatchers\ASTMatchersMacros.h, and it’s defined in clang\Support\Compiler.h. It seems to me that based on the the flags I used (as seen above), the macro CLANG_BUILD_STATIC should be defined as I have none of the dylib flags set.

11

I haven’t had the time to work on this for awhile, but I finally did and I was able to solve the problem. I spent a bunch of time looking through the cmake build script and tried various settings but none worked.

I turns out that all that was needed was to add #define CLANG_BUILD_STATIC in my code before the includes of LLVM headers, and it worked.

Also, the link in the initial post now goes to a working script.

1 Like