musl doesn't provide execinfo.h

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Michał Górny-5
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


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Georgy Yakovlev-2
On Mon, 23 Mar 2020 21:09:15 +0200
Jaco Kroon <[hidden email]> 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 <[hidden email]>

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Joshua Kinard-2
In reply to this post by Jaco Kroon
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
[hidden email]
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

Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Anthony G. Basile
In reply to this post by Joshua Kinard-2
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    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Alexis Ballier-2
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


Reply | Threaded
Open this post in threaded view
|

Re: 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    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Alexis Ballier-2
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


Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Jaco Kroon
In reply to this post by 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: musl doesn't provide execinfo.h

Mike Gilbert-2
On Sat, Mar 28, 2020 at 10:22 AM Jaco Kroon <[hidden email]> 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/