On Fri, 2020-03-27 at 08:03 -0400, Anthony G. Basile wrote: > On 3/26/20 9:25 PM, Joshua Kinard wrote: > > On 3/23/2020 04:21, Jaco Kroon wrote: > > > Hi, > > > > > > https://bugs.gentoo.org/713668 relates. > > > > > > * Searching for /usr/include/execinfo.h ... > > > sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) > > > > > > As I see I can either add an explicit depend on glibc which I'd > > > prefer > > > not to. Or someone from the musl team could possibly assist on > > > how to > > > get the backtrace() set of calls on musl please? > > > > > > Alternatively I need to add a test and simply path debug.c to > > > only > > > provide stub function for print_backtrace(FILE *fp) that just > > > does > > > fprintf(fp, "No backtrace() available to print a backtrace.\n"); > > > > > > Suggestions? > > > > > > Kind Regards, > > > Jaco > > > > Some quick searching on google, it looks like the cleanest fix for > > that bug > > is dahdi-tools needs to be patched to only include execinfo.h or > > only use > > backtrace() on glibc-based systems, and that patch then sent to the > > dahdi-tools upstream developers for inclusion in a future > > release. That > > way, we're not dragging that patch around forever in the tree or in > > the musl > > overlay. > > > > It also doesn't look like musl itself will ever implement > > execinfo.h or > > backtrace(), per this message in 2015 from the lead musl developer: > > https://www.openwall.com/lists/musl/2015/04/09/3 > > > > Correct. I've been adding -standalone packages to provide for > features > like fts, obstack, argp,etc. which are bundled into glibc but not > really > under the POSIX standard. > > So either we patch packages to turn off backtrace() or we add > libunwind-standalone to the tree. >
BTW, we had libexecinfo for fbsd, which seems also present in alpine: https://pkgs.alpinelinux.org/package/edge/main/x86/libexecinfo
