1 |
On 3/23/2020 04:21, Jaco Kroon wrote: |
2 |
> Hi, |
3 |
> |
4 |
> https://bugs.gentoo.org/713668 relates. |
5 |
> |
6 |
> * Searching for /usr/include/execinfo.h ... |
7 |
> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) |
8 |
> |
9 |
> As I see I can either add an explicit depend on glibc which I'd prefer |
10 |
> not to. Or someone from the musl team could possibly assist on how to |
11 |
> get the backtrace() set of calls on musl please? |
12 |
> |
13 |
> Alternatively I need to add a test and simply path debug.c to only |
14 |
> provide stub function for print_backtrace(FILE *fp) that just does |
15 |
> fprintf(fp, "No backtrace() available to print a backtrace.\n"); |
16 |
> |
17 |
> Suggestions? |
18 |
> |
19 |
> Kind Regards, |
20 |
> Jaco |
21 |
|
22 |
Some quick searching on google, it looks like the cleanest fix for that bug |
23 |
is dahdi-tools needs to be patched to only include execinfo.h or only use |
24 |
backtrace() on glibc-based systems, and that patch then sent to the |
25 |
dahdi-tools upstream developers for inclusion in a future release. That |
26 |
way, we're not dragging that patch around forever in the tree or in the musl |
27 |
overlay. |
28 |
|
29 |
It also doesn't look like musl itself will ever implement execinfo.h or |
30 |
backtrace(), per this message in 2015 from the lead musl developer: |
31 |
https://www.openwall.com/lists/musl/2015/04/09/3 |
32 |
|
33 |
-- |
34 |
Joshua Kinard |
35 |
Gentoo/MIPS |
36 |
kumba@g.o |
37 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
38 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
39 |
|
40 |
"The past tempts us, the present confuses us, the future frightens us. And |
41 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
42 |
|
43 |
--Emperor Turhan, Centauri Republic |