Re: Optionally using a better backtrace library?

On Mon Jul 3, 2023 at 12:43 PM CDT, Andres Freund wrote:
> On 2023-07-03 11:58:25 +0200, Alvaro Herrera wrote:
> > On 2023-Jul-02, Andres Freund wrote:
> > > Nice things about libbacktrace are that the generation of stack traces is
> > > documented to be async signal safe on most platforms (with a #define to figure
> > > that out, and a more minimal safe version always available) and that it
> > > supports a wide range of platforms:
> >
> > Sadly, it looks like the library is seldom distributed.
>
> It's often distributed as part of gcc.
>
>
> > For example, Debian seems to only have a package called android-libbacktrace
> > which I imagine is not what we want.
>
> Indeed not.
>
>
> > On my system I see a static library only -- is that enough? That file is
> > part of package libgcc-10-dev, which tells me that we can't depend on that
> > for packaging purposes.
>
> We should be able to depend on that gcc-NN depends on libgcc-NN-dev, it
> contains all the compiler version specific stuff. It's where the intrinsics
> headers, C runtime initialization, sanitizer libraries all live. clang will
> typically also depend on libgcc-NN-dev on unixoid systems.
>
> And since it's statically linked (and needs to be apparently), you don't need
> libgcc-NN-dev installed at runtime.
>
>
> > I think it's pretty much the same in the RPM side of the world.
>
> I don't know much about that side of the world...

I could not find this packaged in Fedora. I did find it in FreeBSD
however. We could add libbacktrace as a Meson subproject.

--
Tristan Partin
Neon (https://neon.tech)