Wierd cmake errors about crashpad_wer.rc written multiple times when building sentry-native on windows

[JanFellner]

I have an issue since longer and still have not found a solution to it.

Sentry native is checked out a subodule in another repository, thus i cannot really change the cmake files.
Thus i am configuring them through the cmake command line parameters

This is the current command line:

cmake -B buildwin32_142 -DSENTRY_BACKEND=crashpad -DCLIENT_STACKTRACES_ENABLED=ON -DSENTRY_INTEGRATION_NONE=OFF -DSENTRY_BUILD_TESTS=OFF -DSENTRY_BUILD_EXAMPLES=OFF -DSENTRY_INTEGRATION_QT=OFF -DSENTRY_BUILD_SHARED_LIBS=OFF -DSENTRY_BUILD_RUNTIMESTATIC=ON -DCMAKE_DEBUG_POSTFIX="d" -DCMAKE_INSTALL_PREFIX=. -DCMAKE_INSTALL_LIBDIR=../lib_142 -DCMAKE_INSTALL_BINDIR=../lib_142 -A Win32 -G "Visual Studio 17 2022" 1>cmake_sentry_native_win32_142.log 2>cmake_sentry_native_win32_142.err

Cmake version is 3.31.6-msvc6. Using sentry-native master head which i just updated

I get really wiered errors about crashpad_wer.rc beeing written multiple time (in total 15 times)

`CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Error in external/crashpad/handler/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

X:/dev/global/libs/sentry-native/buildwin32_vc143/crashpad_build/handler/crashpad_wer.rc

CMake Generate step failed. Build files cannot be regenerated correctly.`

Anybody else having seen this or has a hint how to solve it without patching the error logfile?

[supervacuus]

Hi @JanFellner, the problem here is a classic CMake topic when it comes to multi-config generators.

We produce the resource files for all terminal binaries (.exe/.dll) using generator expressions that vary by config. However, we write the generated resource files not into config-specific folders, which may potentially result in overwrites when the content of the generated files differs.

In a single config generator like Makefiles or Ninja, this will never surface a problem, since there is always only one config. Even in multi-config setups (like the Visual Studio generator), this is usually not a problem because the evaluation file will be written multiple times with the identical content (for each config).

However, in your setup, you specify -DCMAKE_DEBUG_POSTFIX="d" which introduces a config-specific difference in the content, namely the TARGET_FILE_NAME, and we still write it to non-config-specific outputs. And that is the problem we need to fix.

[JanFellner]

It´s damn astonishing how fast you are in finding the root cause of all the issues i am posting .).

Shall i create an issue for this topic?

When it comes to changing the cmake files i also just humbled over something which might need a fix in the cmake files.
Will create another small discussion for it to seperate the topics...

[supervacuus]

It´s damn astonishing how fast you are in finding the root cause of all the issues i am posting .).

You are sometimes lucky with the timing when you post, and when I have a slot to take a look at such issues.

Shall i create an issue for this topic?

Done.

There is also a PR #1383, which you can test locally.

[JanFellner]

Gimme 15 minutes fetching coffee and will give it a try :) 👍

[supervacuus]

The PR is against the latest master, which changes the version handling, so if you apply the patch to util.cmake, you might have to keep the version splitting code if your local checkout still has it.

[JanFellner]

I got mad with all the cloned code on our side 😎
So we started to link all third party code as submodules. sentry is one of em.
Let´s see where i find problems on our side but a full compile takes some time. The cmake output looks good now😍, waiting for all the libs to compile and then i can run a product compile...

[JanFellner]

So cmake output looks good but i get lib linker errors now...

crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__realloc referenced in function _mpack_realloc [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__feof referenced in function "unsigned int __cdecl mpack_file_reader_fill(struct mpack_reader_t *,char *,unsigned int)" (?mpack_file_reader_fill@@YAIPAUmpack_reader_t@@PADI@Z) [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__ferror referenced in function "void __cdecl mpack_file_reader_skip(struct mpack_reader_t *,unsigned int)" (?mpack_file_reader_skip@@YAXPAUmpack_reader_t@@I@Z) [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__fopen referenced in function _mpack_writer_init_filename [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__fread referenced in function "unsigned int __cdecl mpack_file_reader_fill(struct mpack_reader_t *,char *,unsigned int)" (?mpack_file_reader_fill@@YAIPAUmpack_reader_t@@PADI@Z) [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__fseek referenced in function "void __cdecl mpack_file_reader_skip(struct mpack_reader_t *,unsigned int)" (?mpack_file_reader_skip@@YAXPAUmpack_reader_t@@I@Z) [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__ftell referenced in function "void __cdecl mpack_file_reader_skip(struct mpack_reader_t *,unsigned int)" (?mpack_file_reader_skip@@YAXPAUmpack_reader_t@@I@Z) [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
crashpad_mpackd.lib(mpack.obj) : error LNK2019: unresolved external symbol __imp__fwrite referenced in function _mpack_print_file_callback [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]
X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\Debug\crashpad_handler.exe : fatal error LNK1120: 9 unresolved externals [X:\dev\global\libs\sentry-native\buildwin32_vc143\crashpad_build\handler\crashpad_handler.vcxproj]

the mpack project is part of the generated solution, so the project is there but it looks like it is not built when i
msbuild INSTALL.vcxproj
when i open the solution the project is build and i can compile the crashpad_handler.exe

I´m trying to reduce the builds and build time by:

DSENTRY_BUILD_TESTS=OFF
DSENTRY_BUILD_EXAMPLES=OFF
DSENTRY_INTEGRATION_QT=OFF
DSENTRY_BUILD_SHARED_LIBS=OFF

@supervacuus - Is that mpackd part of these?

[JanFellner]

I´m not 100% sure but i assume that the lib needs to be addede here as well?

It is referenced as lib in the crashpad_handler.exe project but built as dll

[JanFellner]

Adding the mpack lib appropriatly solved it for me...
-> #1386

[JanFellner]

closing it as done .)