On 2020-02-28 Mario Emmenlauer wrote:
> It seems I did find an impediment, after all. I've back-ported the
> CMakeLists.txt to xz-5.2.4 as described before. The only change
> required was to remove two source files,
> src/liblzma/common/file_info.c and src/liblzma/common/index_decoder.h.

This should be fine for Windows. There are *minor* details why it's not
perfect for other platforms but those don't matter here.

> But on Windows with VS2017 latest and VS2019 latest, I have problems
> with the processing of liblzma_w32res.rc. Below is the error message
> from nmake, but it fails in a similar (not identical) way with ninja
> build system.

Great to see this tested. It was one thing that I felt unsure if it
will work. Weirdly the error message doesn't say anything else than the
return code which isn't very useful.

>   [ 98%] Building RC object
> CMakeFiles/liblzma.dir/src/liblzma/liblzma_w32res.rc.res
> C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\rc.exe -DDLL_EXPORT
> -IC:\data\Debug\xz-5.2.4\src\common -DWIN32 -D_DEBUG /fo

At least it seems to try to build it with the resource compiler and the
include path had src/common in it so it will find common_w32res.rc too.
Does rc.exe really print nothing? Can you run the command manually?

Can you try if the VS project files under windows/vs* work for building
a DLL? They should build the resource file too and I have an impression
that the project files have been tested, so perhaps there are clues what
is done differently (or if the resource file just isn't compatible). The
project files have seen updates since 5.2.4 too, so please test with
xz.git or using this snapshot:



This sounds like a bug in the CMake files unless MSVC really supports
__builtin_assume_aligned that GCC and Clang support. xz 5.2.4 doesn't
recognize that define so it's harmless there. So this must be fixed too
if it is broken. The above snapshot is good for testing this with CMake.

Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Reply via email to