Hi, So I figured I better write the patch for dahdi-tools against musl ... so I proceed to download a stage3 tar from http://distfiles.gentoo.org/experimental/amd64/musl/ (vanilla).
I extract it, and mount --rebind /dev, /proc and /sys, and copy in /etc/resolve.conf ... chroot ... and so far so good. emerge --sync emerge -uDNav @world. And this blows up on pam-1.3.1-r2. Looks like https://bugs.gentoo.org/687234. I've seen mention of a musl overlay? What's the best way to proceed? As it stands I can't "make prepare" gentoo-sources (which 4.19.X) is apparently the newest available for musl profile. Reports seems to indicate that this be related to "old linux-headers" (which is at ). Kind Regards, Jaco On 2020/03/27 07:43, Jaco Kroon wrote: > Hi, > > On 2020/03/27 03:25, 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. > Thanks. I'll see action accordingly. > >> 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 >> > Implementing libunwind is overkill for my needs, I'll be happy to help > push things upstream if somebody else cares enough to implement. > > Kind Regards, > Jaco > >
