Which library the sentry-native conan recipe should preferably required ?

[MartinDelille]

This is more a question than a bug report so I removed the issue template and will try to be as comprehensive as possible.

I'm maintaining the sentry-native recipe on the conan center index. As you can see there is a pretty high number of package download (5% of the overall release download count according to github API).

There is currently 4 backend option:

• sentry-crashpad
• sentry-breakpad
• crashpad (from google)
• breakpad (from google)

I wondered what could be the issue using the one from google ? It would be simpler to maintain the sentry-native recipe if the default backend where the one from google because it would avoid to update sentry-crashpad and. sentry-breakpad for every minor version. What risk do you see in changing the current default ?

[supervacuus]

Hi @MartinDelille, thanks for your work on the conan recipe. In short: crashpad and breakpad from google aren't tested from our side. Precisely, we do not track which version of crashpad/breadpad is currently available on conan, vcpkg, etc., so we cannot guarantee that any version of the Native SDK is in sync with the changes in that specific package.

There are also a couple of local changes in the sentry forks, like client-side stack traces, having a FirstChanceHandler available on Windows for crashpad (to allow us to fire before_send and on_crash), maintaining compatibility with GCC toolchains (which is an explicit non-goal of the google-devs) and (community-driven) MinGW support (which was broken in 0.4.18, but now seems to get restored). If we look at what the community and our customers want from the Native SDK, it seems there will be further adaptations to the forks rather than fewer.

So, while I understand that this is an additional effort (believe me, it is for us as well, the decision to maintain local forks is not made lightly), my suggestion would be to keep working with the sentry forks.

[MartinDelille]

Thank you very much for this precise answer! Version bumping turns to be easier anyway since there is no more patch to apply since a few versions! People are also working on a bot to do the repetitive task so it should be easier in the future.

[MartinDelille]

It looks like gcc 5 doesn't work with sentry-breakpad 0.5.4 :

• [sentry-breakpad/0.5.4] Bump version conan-io/conan-center-index#15491
• https://c3i.jfrog.io/c3i/misc/logs/pr/15491/5-linux-gcc/sentry-breakpad/0.5.4//f3cc93a9ca553f9d68848c1d9cf0af83131b33ca-build.txt

Any idea what could be the issue ?

[supervacuus]

The problem is that breakpad requires a C++17 compiler. Specifically, the failing static_assert() without a message as the second parameter is not supported in GCC before version 6. If you want to provide broad support for C++17 features (to make the build future-proof), you should update to at least GCC 7 or 8.

[MartinDelille]

Thank you for you help! I managed to make the build go green! 🎉

[Swatinem]

@supervacuus did a good job explaining all the reasoning here.
To clarify, our breakpad fork does not carry any "feature" work, so it should be exchangeable with the upstream breakpad.
There are some fixed for niche things like MIPS signal numbers etc, but those are not blockers.

For crashpad though, as @supervacuus mentioned, we depend on the FirstChanceHandler, and especially proper attachments support which I believe is still not available across all platforms. It would not be possible to use the SDK without these added features.