new custom dependency lookup for libexecinfo

[neheb]

Basically copy/paste from the iconv dependency.

[neheb]

just noticed no BSD CIs. Unfortunate.

[dcbaker]

I've thought about this a few times too, so I'm happy to have it.

We should probably note somewhere that CMake's equivalent is called backtrace

[neheb]

If CMake's equivalent is called backtrace , we should match it here.

[dcbaker]

The only concern I have with that is that there is a libbacktrace. They don't currently provide a pkg-config file (and it doesn't look like any of the distros patch one it, but it seems like a potential for a conflict. I think CMake made the wrong decision 15 years ago, and I don't think we should replicate it. If someone creates a libexecinfo that isn't a re-implementation of this API, that seems like a them problem not an us problem.

[neheb]

OK.

[eli-schwartz]

Given everyone packaging this calls it libexecinfo it's plain we shouldn't call it "backtrace" -- a function name rather than a header + BSD library name.

And for some extra fun: https://github.com/fam007e/libexecinfo

Nobody uses it, author self-uploaded to the AUR. :P Does provide a pkg-config file called... libexecinfo.pc

We will never use method: 'cmake' here so the cmake name is irrelevant.

[dcbaker]

We will never use method: 'cmake' here so the cmake name is irrelevant.

I think it's worth mentioning in the documentation that CMake provides the same functionality as backtrace, I think that's useful information for someone porting. But just in the documentation

And for some extra fun: https://github.com/fam007e/libexecinfo

Nobody uses it, author self-uploaded to the AUR. :P Does provide a pkg-config file called... libexecinfo.pc

So I guess we should provide pkg-config support as well? I'd be in favor of making that the last checked method.

[neheb]

OK done.

[eli-schwartz]

So I guess we should provide pkg-config support as well? I'd be in favor of making that the last checked method.

... maybe? I have mixed feelings about it if it's going to have zero known users. The one place it can be found is a glibc-only distro. Initial commit is last month.

[neheb]

The issue I have with the pkgconfig solution is that it's redundant. The system one will find it. Its pkgconfig file has the base include directory specified.

[dcbaker]

The issue I have with the pkgconfig solution is that it's redundant. The system one will find it. Its pkgconfig file has the base include directory specified.

That's only true if you configure the package with PREFIX=/ and not some other path, right?

[dcbaker]

In particular, nixos has a derivation for libexecinfo, and I wouldn't find it with the .pc file

[neheb]

ah right.

[eli-schwartz]

@dcbaker are you packaging this brand new greenfield project from a month ago, for nixos?

[neheb]

I was curious

https://repology.org/project/libexecinfo/packages

the only usage of that libexecinfo is the AUR.

[dcbaker]

@eli-schwartz: nope, apparently nixos packages the freebsd implementation under that name

[eli-schwartz]

That's why I asked you if you were going to do it. ;)

As I said above -- currently nobody packages it at all, other than

author self-uploaded to the AUR. :P

[thesamesam]

I guess it's fine. These polyfill libraries have a bunch of issues but this one is less problematic than the others in that the naming is consistent, I think.