Fails with a linker error for crashpad

[AudriusButkevicius]

Description

Fails to link.

Not really sure where this issue belongs (crashpad/vcpkg or sentry), but started happening after a random vcpkg rebuild.
I'm certain I had it pinned to version 0.5.0, so I can'see what could have caused it.

When does the problem happen

• During build
• During run-time
• When capturing a hard crash

Environment

• OS: Windows 10, 64bit
• Compiler: 14.29.30133
• CMake version and config: vcpkg provided

Steps To Reproduce

Use vcpkg package with x64-windows-static triplet
Build

Log output

0>crashpad_client.lib(crashpad_client_win.cc.obj): Error LNK2001 : unresolved external symbol __std_find_trivial_8

[supervacuus]

Hello @AudriusButkevicius. I looked into reproducing this, even without vcpkg, but was unable to. The specific unresolved symbol for crashpad_client_win.cc is curious (because if you can't resolve std::find, you'd probably have problems resolving other functions, too), so I had a look at whether other projects have a similar issue.

It seems like an issue when updating VisualStudio and keeping the artifacts of vcpkg built with the previous VS: actions/runner-images#6091.

I think the vcpkg people might know more about this than we do.

[AudriusButkevicius]

I know std::find is there as its used in other parts of the code, perhaps not the same specialisation.

Moving to toolset v143 seems to have solved it, so I think its potentially msvc2019 does not have that specific specialisation of std::find, and it was somehow picking up a different version of the standard library by some way?

Not sure. Regardless it's solved, so closing.

I'll raise a separate issue with vcpkg to allow picking different backend as features. For my use-case I just report messages from the application, so I don't need any backend at all, but seems you can't have "none" via vcpkg.

[supervacuus]

Moving to toolset v143 seems to have solved it, so I think its potentially msvc2019 does not have that specific specialisation of std::find, and it was somehow picking up a different version of the standard library by some way?

The solution in the referenced issue was to automate the vs_installer to remove a conflicting compiler set, so yeah, I guess the toolchain/library conflict.