Build for VS2019 on Win7 using Release Configuration might require SEH

[Username256]

Description
CMake generates Visual studio projects that use /EHsc exception handling specification. In the project properties, under C++ in the Code Generation field, Cmake puts this /EHsc value.

But building a dll or exe file might result in linker errors with unresolved externals when building a Release build of your project. An option can be passed to cmake generator that will fix this problem should it occur. Maybe this is for docs? See the cmake command line snippet below and how it specifies to use /EHa. This can be then used to build the sentry library in Release config so that it links without errors to a Release mode build of some application linking the sentry lib into it.

When does the problem happen
When trying to build a project in Release config, and the project links to sentry library with crashpad backend that was built using Release or RelWithDebInfo configs.

• [ x] During build
• During run-time
• When capturing a hard crash

Environment

• OS: Win7 Sp1
• Compiler: Visual Studio 2019
• CMake version and config: See code snippet below

Steps To Reproduce

cmake -S"../../../Source/sentry-native" -Bbuild -G"Visual Studio 16 2019" -DSENTRY_BACKEND=crashpad -DSENTRY_BUILD_SHARED_LIBS=0 -DCMAKE_SYSTEM_VERSION=10.0 -DCMAKE_CXX_FLAGS="/EHa"

Log output

[supervacuus]

I am not sure I follow your analysis here:

But building a dll or exe file might result in linker errors with unresolved externals when building a Release build of your project.

Which linker errors do you observe? How do they relate to the build-config (Release, etc.)?

CMake generates Visual studio projects that use /EHsc exception handling specification. In the project properties, under C++ in the Code Generation field, Cmake puts this /EHsc value.

This is not by accident. /EHsc matches the expectation of the Native SDK (there are no C++ exceptions in our code base since all vendored dependencies in C++ follow the Google style guide (the sentry code itself is written in C), so there is no need to "catch" (as in C++ catch not SEH __except) asynchronous exceptions (we actually want them to land in our globally installed UnhandledExceptionFilter so we can report them). How does switching to /EHa solve your linker errors?

[Username256]

I am building a .dll that links to sentry using crashpad as backend.

Compiler - VS 2019 on Windows 7

I will try to illustrate this by some specifications of each scenario...

A) Use CMake to generate without specifying /EHa .This generates /EHsc in all the projects for sentry for VS2019.

1. Debug Config
   MyDLL = Debug /EHsc
   Sentry Lib= Debug /EHsc
   All works fine.
2. Release Config
   MyDLL = Release /EHsc
   Sentry Lib = Release /EHsc
   ERRORS! Causes linker errors with unresolved externals. Cannot find std_find_xyz etc...

B) Use CMake to generate and specify /EHa .This generates /EHa in all the projects for sentry for VS2019.

1. Debug Config
   MyDLL = Debug /EHa
   Sentry Lib= Debug /EHa
   All works fine.
2. Release Config
   MyDLL = Release /EHa
   Sentry Lib = Release /EHa
   Works fine. Linker errors go away.

In other words, I think a small documentation item is needed to mention that for VS2019 you can specify /EHa when configuring sentry, if it is the case that the default flags generated by cmake for sentry cause linker errors when building a program linked to sentry.

For example:
If VS 2019 complains with linker errors when linking to sentry, try adding -DCMAKE_CXX_FLAGS="/EHa" to the CMake command line.

This is similar to This Error
involving std_find that you have seen before. I searched for an example of it and found you in the comments! But in this case it is like std_find_trivial and one other function related to C++ exception handling. I think its a bug in VS2019. But for me I can just use slow SEH makes no difference to my requirements and sentry works fine.