[gentoo-dev] musl doesn't provide execinfo.h

[gentoo-dev] musl doesn't provide execinfo.h

[Jaco Kroon]

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

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Mon, 2020-03-23 at 10:21 +0200, 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?
> 

As someone not on musl team, I think libunwind provides
an implementation of backtrace().

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Jaco Kroon]

Hi Michał,

On 2020/03/23 18:25, Michał Górny wrote:

> On Mon, 2020-03-23 at 10:21 +0200, 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?
>>
> As someone not on musl team, I think libunwind provides
> an implementation of backtrace().
>
Thanks.  That indeed looks interesting.

Let's say I do go that route rather than simply no-opping it, would I
add a BDEPEND + RDEPEND of the form:

|| ( sys-libs/glibc sys-libs/libunwind )

To the ebuild?

The code (./configure and actual "C" I'll manage).

Kind Regards,
Jaco

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Georgy Yakovlev]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On Mon, 23 Mar 2020 21:09:15 +0200
Jaco Kroon <jaco@uls.co.za> wrote:

> Hi Michał,
> 
> On 2020/03/23 18:25, Michał Górny wrote:
> 
> > On Mon, 2020-03-23 at 10:21 +0200, 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?
> >>
> > As someone not on musl team, I think libunwind provides
> > an implementation of backtrace().
> >
> Thanks.  That indeed looks interesting.
> 
> Let's say I do go that route rather than simply no-opping it, would I
> add a BDEPEND + RDEPEND of the form:
> 
> || ( sys-libs/glibc sys-libs/libunwind )
> 
> To the ebuild?
> 
> The code (./configure and actual "C" I'll manage).
> 
> Kind Regards,
> Jaco
> 
> 

if libunwind can be used, you should use this dep

    elibc_musl? ( sys-libs/libunwind:= )

but idk if it's usable as is on musl.
best way to check is to get musl stage3 tarball and test it.
alpine does have a musl patch, but it seems they just patch it out completely.
https://git.alpinelinux.org/aports/tree/main/dahdi-tools/fix-musl.patch



-- 
Georgy Yakovlev <gyakovlev@gentoo.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Joshua Kinard]

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

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Jaco Kroon]

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

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Anthony G. Basile]

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.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Alexis Ballier]

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

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Anthony G. Basile]

On 3/27/20 3:17 PM, Alexis Ballier wrote:
> 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
> 
> 


Had?  Is it in the tree now or should I look into adding it?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Alexis Ballier]

On Fri, 2020-03-27 at 19:07 -0400, Anthony G. Basile wrote:
> On 3/27/20 3:17 PM, Alexis Ballier wrote:
> > 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
> > 
> > 
> 
> Had?  Is it in the tree now or should I look into adding it?

Restoring it: https://bugs.gentoo.org/683284

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Jaco Kroon]

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
>
>

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Mike Gilbert]

On Sat, Mar 28, 2020 at 10:22 AM Jaco Kroon <jaco@uls.co.za> wrote:
>
> 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?

Either add sys-libs/pam to package.accept_keywords to pick the latest
fixes, or fetch/enable this overlay:
https://gitweb.gentoo.org/proj/musl.git/