> With this patch i boot up a hurd system with flavio scripts.
Can we get a link to these scripts, please? So we know why they care
about these symbols being in libc.
zw
On Tue, Jan 3, 2023, at 1:28 PM, Samuel Thibault wrote:
> Zack Weinberg via Libc-alpha, le mar. 03 janv. 2023 12:22:20 -0500, a ecrit:
>> > With this patch i boot up a hurd system with flavio scripts.
>>
>> Can we get a link to these scripts, please? So we know why
On Fri, Jan 19, 2018 at 10:11 AM, Joseph Myers wrote:
> On Fri, 19 Jan 2018, Thomas Schwinge wrote:
>
> The source file sysdeps/mach/hurd/bits/errno.h is generated from sources
> including some headers from those components. I don't know how often
> those may change in ways that affect that heade
On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault
wrote:
> Hello,
>
> Thanks a lot for the feedback on what needs to be done. It was a busy
> week-end :)
>
> We should be almost there, I believe I had addressed in
> sthibaul/hurd-builds all requirements except a few remaining bits:
Is it still ex
On Mon, Mar 19, 2018 at 11:46 AM, Samuel Thibault
wrote:
> Zack Weinberg, on lun. 19 mars 2018 11:36:18 -0400, wrote:
>> On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault
>> wrote:
>> > Hello,
>> >
>> > Thanks a lot for the feedback on what need
On Tue, Apr 3, 2018 at 5:58 PM, Samuel Thibault wrote:
> Joseph Myers, on mar. 03 avril 2018 21:48:32 +, wrote:
>> The build for i686-gnu also fails using GCC 6 branch with
>> build-many-glibcs.py:
>>
>> hurdsig.c: In function 'interrupted_reply_port_location.isra.1':
>> hurdsig.c:250:39: erro
On Wed, Apr 18, 2018 at 7:13 AM, Joseph Myers wrote:
> On Wed, 18 Apr 2018, Samuel Thibault wrote:
>
>> Joseph Myers, le mar. 17 avril 2018 23:02:45 +, a ecrit:
>> > On Wed, 18 Apr 2018, Samuel Thibault wrote:
>> >
>> > > The patch below would just introduce bits/types/struct___sched_param.h.
On Wed, Apr 18, 2018 at 10:03 AM, Samuel Thibault
wrote:
>>
>> I have a concern: the types 'struct sched_param' and 'struct
>> __sched_param' are not compatible, even if their members are identical
>> (6.2.7p1 explicitly requires the tags to be the same for
>> compatibility).
>
> Ah, probably that
