llvm-rc.exe failing when regular rc.exe does not

[Tagglink]

I'm on Windows 10 compiling FreeGLUT version 3.2.1 (latest as of here: http://freeglut.sourceforge.net) from source using my own compiled version of Clang 10.0.0 (latest commit as of yesterday) with CMake and Ninja.

Reproduction:
First I configured and built the FreeGLUT project like so:

C:\Playspace\freeglut-3.2.1> cmake -G Ninja -B ninja-build
C:\Playspace\freeglut-3.2.1> cd ninja-build
C:\Playspace\freeglut-3.2.1\ninja-build> ninja

This crashes llvm-rc with the error "expected yet unread fixed VERSIONINFO statement type, got FILEFLAGS":

C:\Playspace\freeglut-3.2.1\ninja-build> ninja
[31/132] Building RC object CMakeFiles/freeglut.dir/freeglut.rc.res
FAILED: CMakeFiles/freeglut.dir/freeglut.rc.res
C:\PROGRA~1\LLVM\bin\llvm-rc.exe -DFREEGLUT_EXPORTS -DHAVE_CONFIG_H -DWINVER=0x0601 -D_CRT_SECURE_NO_WARNINGS -D_WIN32_WINNT=0x0601 -Dfreeglut_EXPORTS -IC:/Playspace/freeglut-3.2.1/src -IC:/Playspace/freeglut-3.2.1/include -IC:/Playspace/freeglut-3.2.1/ninja-build  /fo CMakeFiles/freeglut.dir/freeglut.rc.res C:/Playspace/freeglut-3.2.1/ninja-build/freeglut.rc
llvm-rc: Error parsing file: expected yet unread fixed VERSIONINFO statement type, got FILEFLAGS

Configuring the project like this results in a successful build:

C:\Playspace\freeglut-3.2.1> cmake -G Ninja -B ninja-test-build -DCMAKE_RC_COMPILER:FILEPATH="C:/Program Files (x86)/Windows Kits/10/bin/10.0.18362.0/x64/rc.exe" -DCMAKE_BUILD_TYPE:STRING=Release
C:\Playspace\freeglut-3.2.1> cd ninja-test-build
C:\Playspace\freeglut-3.2.1\ninja-test-build> ninja

i.e. using the windows binary for the rc compiler works right away. This is ok, but it seems something is wrong with llvm-rc.

[mstorsjo]

I would presume that this happens because the freeglut rc file contains preprocessor directives, see e.g. https://github.com/dcnieho/FreeGLUT/blob/git_master/freeglut/freeglut/freeglut.rc.in#L8-L12.

llvm-rc in itself isn't a full replacement for rc.exe at the moment; it doesn't run the C preprocessor, but expects the caller to have done that beforehand. (In llvm-mingw, that's done with a small frontend wrapper tool that implements the GNU windres command line syntax: https://github.com/mstorsjo/llvm-mingw/blob/master/wrappers/windres-wrapper.c#L303-L350

[Tagglink]

I don't really know how regular .rc files are, I'm a novice at open source compilation. This just feels like a small bump in the road to compiling CMake projects using Ninja and Clang on Windows 10. Maybe it could be considered a backlog feature?

I will stick to using the Windows binary for now since the prospect of contributing a non-mingw C preprocessor to LLVM is a little daunting to me.

Thanks for the reply!

[ericastor]

FWIW, this can be fixed in two ways I know of:

1. The mostly-manual option. Whenever using llvm-rc, your build script should first run cl or clang-cl with parameters /P /DRC_INVOKED /Tc<rc file path> /Fi<temporary file path> <most other flags passed to llvm-rc>... this preprocesses the .rc file and stores the result in the temporary location. You can then run llvm-rc on the resulting temporary file, which will hold the preprocessed results. (Of course, we could ship a script that used this logic to make it easier.)

2. Integrate clang's C preprocessor into llvm-rc. This might be a bit tricky, since it crosses LLVM project boundaries... or we could move llvm-rc into the clang project. But we at least shouldn't need to build a preprocessor from scratch.

Neither of these makes it into a perfect drop-in replacement for rc.exe; it turns out that rc.exe's preprocessor isn't quite a full C preprocessor, and will silently fail to act on certain directives under conditions that may not be completely documented. (e.g., I believe it ignores #include commands that include files with unrecognized extensions, such as .inc.) But... it's pretty close, and can be handled by (when something shouldn't be included) checking the RC_INVOKED macro, which Microsoft documents to be defined when rc.exe is processing a file.

[mstorsjo]

FWIW, this can be fixed in two ways I know of:

1. The mostly-manual option. Whenever using llvm-rc, your build script should first run cl or clang-cl with parameters /P /DRC_INVOKED /Tc<rc file path> /Fi<temporary file path> <most other flags passed to llvm-rc>... this preprocesses the .rc file and stores the result in the temporary location. You can then run llvm-rc on the resulting temporary file, which will hold the preprocessed results. (Of course, we could ship a script that used this logic to make it easier.)

This is what I do in my existing GNU windres compatible frontend.

2. Integrate clang's C preprocessor into llvm-rc. This might be a bit tricky, since it crosses LLVM project boundaries... or we could move llvm-rc into the clang project. But we at least shouldn't need to build a preprocessor from scratch.

Neither of these makes it into a perfect drop-in replacement for rc.exe; it turns out that rc.exe's preprocessor isn't quite a full C preprocessor, and will silently fail to act on certain directives under conditions that may not be completely documented. (e.g., I believe it ignores #include commands that include files with unrecognized extensions, such as .inc.) But... it's pretty close, and can be handled by (when something shouldn't be included) checking the RC_INVOKED macro, which Microsoft documents to be defined when rc.exe is processing a file.

FWIW, I don't think the preprocessor execution itself is much different from a normal C preprocessor, but there's a rather vital gotcha; see 518b6c9 and https://docs.microsoft.com/en-us/windows/win32/menurc/preprocessor-directives?redirectedfrom=MSDN. The RC preprocessor does include everything as usual, but ignores the output contributed from files with a .c and .h suffix. This can be observed when feeding the output from a separate preprocessor run; the #line markers are essential for this to work; if they're stripped out, rc.exe will start interpreting everything as resource statements, while the .h files might have contributed e.g. typedefs.