Issue with windres/rc

[DeadSix27]

I'm not quite sure what's happening here, but I was trying to compile lzma with the llvm-mingw toolchain and got into this issue:
llvm-rc: Error parsing file: Invalid token found at position 635
Looked into the resource file:

/*
 * Author: Lasse Collin
 *
 * This file has been put into the public domain.
 * You can do whatever you want with this file.
 */

#define MY_TYPE VFT_APP
#define MY_NAME "xzdec"
#define MY_SUFFIX ".exe"
#define MY_DESC "xzdec decompression tool for .xz files"
#include "common_w32res.rc"

(check the git for the other rc files here: https://github.com/tukaani-project/xz/tree/master/src/xzdec

Looked for position 635, couldn't really figure out the issue here.. any advice?

The lzma cmake script runs windres via this command line:

x86_64-w64-mingw32-windres -O coff -DHAVE_CHECK_CRC32 -DHAVE_CHECK_CRC64 -DHAVE_CHECK_SHA256 -DHAVE_DECODERS -DHAVE_DECODER_ARM -DHAVE_DECODER_ARM64 -DHAVE_DECODER_ARMTHUMB -DHAVE_DECODER_DELTA -DHAVE_DECODER_IA64 -DHAVE_DECODER_LZMA1 -DHAVE_DECODER_LZMA2 -DHAVE_DECODER_POWERPC -DHAVE_DECODER_SPARC -DHAVE_DECODER_X86 -DHAVE_ENCODERS -DHAVE_ENCODER_ARM -DHAVE_ENCODER_ARM64 -DHAVE_ENCODER_ARMTHUMB -DHAVE_ENCODER_DELTA -DHAVE_ENCODER_IA64 -DHAVE_ENCODER_LZMA1 -DHAVE_ENCODER_LZMA2 -DHAVE_ENCODER_POWERPC -DHAVE_ENCODER_SPARC -DHAVE_ENCODER_X86 -DHAVE_INTTYPES_H -DHAVE_LZIP_DECODER -DHAVE_MF_BT2 -DHAVE_MF_BT3 -DHAVE_MF_BT4 -DHAVE_MF_HC3 -DHAVE_MF_HC4 -DHAVE_STDBOOL_H -DHAVE_STDINT_H -DHAVE__BOOL -DHAVE___BUILTIN_ASSUME_ALIGNED -DHAVE___BUILTIN_BSWAPXX -DLZMA_API_STATIC -DMYTHREAD_VISTA -DPACKAGE_BUGREPORT=\"xz@tukaani.org\" -DPACKAGE_NAME="\"XZ Utils\"" -DPACKAGE_URL=\"https://tukaani.org/xz/\" -DTUKLIB_FAST_UNALIGNED_ACCESS -I /sources/lzma/src/common -I /sources/lzma/src/liblzma/api /sources/lzma/src/xzdec/xzdec_w32res.rc CMakeFiles/xzdec.dir/src/xzdec/xzdec_w32res.rc.res llvm-rc: Error parsing file: Invalid token found at position 635

[mstorsjo]

Thanks for reporting, and sorry for the slow response on this one.

This one is a surprisingly tricky case. Actually, things worked fine with the older releases based on LLVM 15 and 16 - upstream xz even seems to have done some manual workarounds specifically for llvm-windres - see tukaani-project/xz@6b117d3.

However a recent change in llvm-rc, llvm/llvm-project@0f4c6b1, which made one detail in llvm-windres match GNU windres better (fixing a discrepancy noted in llvm/llvm-project#57334), actually turned out to break the llvm-windres specific handling used in xz.

So far, the canonical way of passing such strings to windres, that works both with GNU windres and LLVM windres, would be to invoke it with e.g. -DPACKAGE_NAME=\\\"XZUtils\\\" - as the default use of popen() in GNU windres eats one layer of quoting so things need to be doubly escaped. That works fine across both tools. But if xz would use that in their CMakeLists.txt in add_compile_definitions, it would also be passed in that doubly escaped form to the compiler when compiling regular C files, and that breaks things.

I hadn't realized that the --use-temp-file flag to GNU windres actually removes this extra layer of escaping/unescaping by not using popen() but a function that preserves these special characters correctly. This isn't yet implemented in llvm-windres, but I'll try to get that implemented soon. With that implemented, the llvm-windres specific handling in https://github.com/tukaani-project/xz/blob/6b117d3b1fe91eb26d533ab16a2e552f84148d47/CMakeLists.txt#L96-L106 could be removed and the codepath used for the GNU tools could be used for both.

[DeadSix27]

Ah I actually was on the right path thinking it's to do with escaping.

but I'll try to get that implemented soon.

That's good to know.

[mstorsjo]

Ah I actually was on the right path thinking it's to do with escaping.

but I'll try to get that implemented soon.

That's good to know.

https://reviews.llvm.org/D159223 does that - with that applied and the llvm-windres specific case in xz removed, it should work again.

[DeadSix27]

Thanks! I'll test it later then.

PS: Unrelated but, did you look at my other issue already?

[mstorsjo]

This seems to have been fixed in tukaani-project/xz@0570308.