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

2020-03-28 Thread Mike Gilbert
On Sat, Mar 28, 2020 at 10:22 AM Jaco Kroon  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/



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

2020-03-28 Thread 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

2020-03-27 Thread 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

2020-03-27 Thread 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: bluen...@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

2020-03-27 Thread 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

2020-03-27 Thread 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: bluen...@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

2020-03-26 Thread 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

2020-03-26 Thread 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
ku...@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

2020-03-23 Thread Georgy Yakovlev
On Mon, 23 Mar 2020 21:09:15 +0200
Jaco Kroon  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 


pgpb0FaDXw7ig.pgp
Description: PGP signature


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

2020-03-23 Thread 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

2020-03-23 Thread Michał Górny
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
Description: This is a digitally signed message part


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

2020-03-23 Thread 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