Re: Upstreaming the glibc Hurd port

Hello, Samuel Thibault, le jeu. 19 avril 2018 01:57:49 +0200, a ecrit: > I'd tend to think that we do not have any 64bit port using > ./sysvipc/sys/shm.h (I meant include/bits/shm.h here) > or ./sysdeps/gnu/bits/shm.h, and thus we can just fix them into size_t > since on 32bit ports it is ABI-comp

Re: Upstreaming the glibc Hurd port

Joseph Myers, le mar. 03 avril 2018 00:10:30 +, a ecrit: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's > > l_type/l_whence being int instead of short. > > Where something is problematic to fix, because a fix would break the

Re: Upstreaming the glibc Hurd port

Zack Weinberg, le mer. 18 avril 2018 14:40:29 -0400, a ecrit: > 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 req

Re: Upstreaming the glibc Hurd port

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

Re: Upstreaming the glibc Hurd port

Zack Weinberg, le mer. 18 avril 2018 09:54:53 -0400, a ecrit: > 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: > >> > > >>

Re: Upstreaming the glibc Hurd port

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.

Re: Upstreaming the glibc Hurd port

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. > > > and bits/types/struct_sched_param.h for all ports sinc

Re: Upstreaming the glibc Hurd port

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. > > and bits/types/struct_sched_param.h for all ports since it's the same. > > A bits/types/struct_sched_param.h

Re: Upstreaming the glibc Hurd port

On Wed, 18 Apr 2018, Samuel Thibault wrote: > The patch below would just introduce bits/types/struct___sched_param.h. > and bits/types/struct_sched_param.h for all ports since it's the same. A bits/types/struct_sched_param.h that does "#define sched_param __sched_param" is not appropriate for Li

Re: Upstreaming the glibc Hurd port

Hello, Joseph Myers, le mar. 03 avril 2018 00:13:43 +, a ecrit: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote: > > > There are a few remaining namespace issues due to missing __ marking or > > > spurious #includes. > > > > One is

Re: Upstreaming the glibc Hurd port

On 04/03/2018 11: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: error: 'portloc' may be us

Re: Upstreaming the glibc Hurd port

On Tue, 3 Apr 2018, Zack Weinberg wrote: > 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 'interrupt

Re: Upstreaming the glibc Hurd port

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

Re: Upstreaming the glibc Hurd port

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: error: 'portloc' may be used uninitialized in this function > [-

Re: Upstreaming the glibc Hurd port

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: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized] *(volatile mach_port_t *) portloc = *por

Re: Upstreaming the glibc Hurd port

Joseph Myers, on mar. 03 avril 2018 15:45:13 +, wrote: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > > This means that build-glibcs i686-gnu now builds fine. Among the > > remaining TODOs, there are > > If you use mainline GCC, however, it fails: > > ../sysdeps/mach/hurd/if_index.c: In f

Re: Upstreaming the glibc Hurd port

On Mon, 2 Apr 2018, Samuel Thibault wrote: > This means that build-glibcs i686-gnu now builds fine. Among the > remaining TODOs, there are If you use mainline GCC, however, it fails: ../sysdeps/mach/hurd/if_index.c: In function '__if_nametoindex': ../sysdeps/mach/hurd/if_index.c:40:3: error: 's

Re: Upstreaming the glibc Hurd port

On Mon, 2 Apr 2018, Samuel Thibault wrote: > Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote: > > There are a few remaining namespace issues due to missing __ marking or > > spurious #includes. > > One issue is with struct sched_param. The __sched_param definition > was removed in g

Re: Upstreaming the glibc Hurd port

On Mon, 2 Apr 2018, Samuel Thibault wrote: > Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's > l_type/l_whence being int instead of short. Where something is problematic to fix, because a fix would break the ABI or needs some external feature, there is an xfail mechanism inte

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on lun. 02 avril 2018 19:35:11 +0200, wrote: > > configure:4096: checking lex library > > configure:4110: gcc -o conftest -g -O2 conftest.c >&5 > > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input': > > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.

Re: Upstreaming the glibc Hurd port

H.J. Lu, on lun. 02 avril 2018 10:22:31 -0700, wrote: > On Mon, Apr 2, 2018 at 10:15 AM, Samuel Thibault > wrote: > > H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote: > >> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault > >> wrote: > >> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote

Re: Upstreaming the glibc Hurd port

On Mon, Apr 2, 2018 at 10:15 AM, Samuel Thibault wrote: > H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote: >> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault >> wrote: >> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: >> >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault >> >> wr

Re: Upstreaming the glibc Hurd port

H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote: > On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault > wrote: > > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: > >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault > >> wrote: > >> > Hello, > >> > > >> > Joseph Myers, on lun. 02 avril

Re: Upstreaming the glibc Hurd port

On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault wrote: > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault >> wrote: >> > Hello, >> > >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +, wrote: >> >> On Mon, 2 Apr 2018, Samuel Thibault w

Re: Upstreaming the glibc Hurd port

On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault wrote: > Hello, > > Joseph Myers, on lun. 02 avril 2018 14:22:28 +, wrote: >> On Mon, 2 Apr 2018, Samuel Thibault wrote: >> >> > This means that build-glibcs i686-gnu now builds fine. Among the >> > remaining TODOs, there are >> >> Thanks! I'd

Re: Upstreaming the glibc Hurd port

H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: > On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault > wrote: > > Hello, > > > > Joseph Myers, on lun. 02 avril 2018 14:22:28 +, wrote: > >> On Mon, 2 Apr 2018, Samuel Thibault wrote: > >> > >> > This means that build-glibcs i686-gnu now buil

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote: > There are a few remaining namespace issues due to missing __ marking or > spurious #includes. One issue is with struct sched_param. The __sched_param definition was removed in glibc while htl's pthread_attr uses it. For now I just m

Re: Upstreaming the glibc Hurd port

Joseph Myers, on lun. 02 avril 2018 14:17:38 +, wrote: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > > - header standard conformity issues: These will be hard to fix. > > What are the issues here? Some of these are small, like ./bits/types/sigevent_t.h's sigev_notify_attributes not being

Re: Upstreaming the glibc Hurd port

Hello, Joseph Myers, on lun. 02 avril 2018 14:22:28 +, wrote: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > > This means that build-glibcs i686-gnu now builds fine. Among the > > remaining TODOs, there are > > Thanks! I'd add: the "requires out-of-tree patches" statement in README > ne

Re: Upstreaming the glibc Hurd port

On Mon, 2 Apr 2018, Samuel Thibault wrote: > This means that build-glibcs i686-gnu now builds fine. Among the > remaining TODOs, there are Thanks! I'd add: the "requires out-of-tree patches" statement in README needs to be removed, and a NEWS entry is needed. Will you be able to provide full

Re: Upstreaming the glibc Hurd port

On Mon, 2 Apr 2018, Samuel Thibault wrote: > - header standard conformity issues: These will be hard to fix. What are the issues here? > - elf/check-localplt: There will always be PLTs to libhurd/machuser.so > anyway. If a library has *local* PLT entries - PLT entries for within-library call

Re: Upstreaming the glibc Hurd port

Florian Weimer, on lun. 02 avril 2018 09:51:00 +0200, wrote: > On 04/02/2018 02:10 AM, Samuel Thibault wrote: > > - elf/check-execstack: We have nested functions which make the stack > >executable indeed. > > I looked at the Hurd situation last month. Hurd is always > read-implies-exec, I thi

Re: Upstreaming the glibc Hurd port

On 04/02/2018 02:10 AM, Samuel Thibault wrote: - elf/check-execstack: We have nested functions which make the stack executable indeed. I looked at the Hurd situation last month. Hurd is always read-implies-exec, I think. So there is no need to make the stacks executable, it does not have

Re: Upstreaming the glibc Hurd port

Hello, So, after various coding style fixes etc. I eventually pushed htl. This means that build-glibcs i686-gnu now builds fine. Among the remaining TODOs, there are - making testsuite pass - fixing the generated errno file thing - sharing tests between nptl and htl - sharing pthread.h - C11 th

Re: Upstreaming the glibc Hurd port

Svante Signell, on dim. 01 avril 2018 14:05:10 +0200, wrote: > Well, Ive looked into the libpthread files and compared with nptl > versions, see the attached file. I seems like most nptl files are > missing the first line comments not the libpthread (i.e. Hurd) files. Ok. I added the missing ones

Re: Upstreaming the glibc Hurd port

On Tue, 2018-03-27 at 09:20 +0200, Samuel Thibault wrote: > Svante Signell, on mar. 27 mars 2018 02:54:06 +0200, wrote: > > On Tue, 2018-03-27 at 00:50 +0200, Samuel Thibault wrote: > > > Svante Signell, on lun. 26 mars 2018 23:53:31 +0200, wrote: > > > > On Mon, 2018-03-19 at 02:52 +0100, Samuel T

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > - Two patches pending comments on libc-alpha: > [PATCH] hurd: Initialize TLS and libpthread before signal thread start > [PATCH] hurd: Fix early rtld access to errno That is done. > - plugging the htl tests to the glibc test infra

Re: Upstreaming the glibc Hurd port

Tulio Magno Quites Machado Filho, on mar. 27 mars 2018 11:46:32 -0300, wrote: > Are these all the patches pending an update there? > https://patchwork.sourceware.org/project/glibc/list/?submitter=384 No, it's not all of them, so it's really me who should work it out :) Carlos O'Donell, on mar. 27

Re: Upstreaming the glibc Hurd port

Samuel Thibault writes: > Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: >> 19.03.2018 02:51 Samuel Thibault wrote: >> > Thanks a lot for the feedback on what needs to be done. It was a busy >> > week-end :) >> >> I appreciate your work. :-) Sorry for a kinda off-topic but could yo

Re: Upstreaming the glibc Hurd port

On 03/27/2018 09:46 AM, Tulio Magno Quites Machado Filho wrote: > Samuel Thibault writes: > >> Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: >>> 19.03.2018 02:51 Samuel Thibault wrote: Thanks a lot for the feedback on what needs to be done. It was a busy week-end :) >>> >

Re: Upstreaming the glibc Hurd port

27.03.2018 12:43 Samuel Thibault wrote: > Rafal Luzynski, on mar. 27 mars 2018 12:40:27 +0200, wrote: > > 27.03.2018 11:00 Samuel Thibault wrote: > > > [...] > > > It seems I can't mark patches submitted by other people, perhaps I just > > > need to be added to the "Maintainers" list? > > > > No,

Re: Upstreaming the glibc Hurd port

Rafal Luzynski, on mar. 27 mars 2018 12:40:27 +0200, wrote: > 27.03.2018 11:00 Samuel Thibault wrote: > > [...] > > It seems I can't mark patches submitted by other people, perhaps I just > > need to be added to the "Maintainers" list? > > No, I wouldn't ask you to mark patches by other people, i

Re: Upstreaming the glibc Hurd port

27.03.2018 09:45 Samuel Thibault wrote: > [...] > Oh, I didn't know about it. Is there a way to make them marked as > commited right from the mail subject, for future commits? I don't know. Any hints, anybody? 27.03.2018 11:00 Samuel Thibault wrote: > [...] > It seems I can't mark patches subm

Re: Upstreaming the glibc Hurd port

Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: > 19.03.2018 02:51 Samuel Thibault wrote: > > Thanks a lot for the feedback on what needs to be done. It was a busy > > week-end :) > > I appreciate your work. :-) Sorry for a kinda off-topic but could you > please visit the Patchwork si

Re: Upstreaming the glibc Hurd port

Hello, Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: > I appreciate your work. :-) Sorry for a kinda off-topic but could you > please visit the Patchwork site [1] and mark your committed patches > as committed, or ask someone to do it for you? Oh, I didn't know about it. Is there a

Re: Upstreaming the glibc Hurd port

Svante Signell, on mar. 27 mars 2018 02:54:06 +0200, wrote: > On Tue, 2018-03-27 at 00:50 +0200, Samuel Thibault wrote: > > Svante Signell, on lun. 26 mars 2018 23:53:31 +0200, wrote: > > > On Mon, 2018-03-19 at 02:52 +0100, Samuel Thibault wrote: > > > > Samuel Thibault, on lun. 19 mars 2018 02:51

Re: Upstreaming the glibc Hurd port

On Tue, 2018-03-27 at 00:50 +0200, Samuel Thibault wrote: > Svante Signell, on lun. 26 mars 2018 23:53:31 +0200, wrote: > > On Mon, 2018-03-19 at 02:52 +0100, Samuel Thibault wrote: > > > Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > > > > - Fixing GNU Coding Style, notably first l

Re: Upstreaming the glibc Hurd port

Hello Samuel, 19.03.2018 02:51 Samuel Thibault wrote: > > Hello, > > Thanks a lot for the feedback on what needs to be done. It was a busy > week-end :) I appreciate your work. :-) Sorry for a kinda off-topic but could you please visit the Patchwork site [1] and mark your committed patches as co

Re: Upstreaming the glibc Hurd port

Svante Signell, on lun. 26 mars 2018 23:53:31 +0200, wrote: > On Mon, 2018-03-19 at 02:52 +0100, Samuel Thibault wrote: > > Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > > > - Fixing GNU Coding Style, notably first line of files. > > > > Could people have a look in the libpthread

Re: Upstreaming the glibc Hurd port

On Mon, 2018-03-19 at 02:52 +0100, Samuel Thibault wrote: > Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > > - Fixing GNU Coding Style, notably first line of files. > > Could people have a look in the libpthread repository? > Most probably, for a lot of these files, one can just ta

Re: Upstreaming the glibc Hurd port

Zack Weinberg, on lun. 19 mars 2018 11:54:21 -0400, wrote: > 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

Re: Upstreaming the glibc Hurd port

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 needs to be done. It was a busy >> > week-end :) >> > >>

Re: Upstreaming the glibc Hurd port

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

Re: Upstreaming the glibc Hurd port

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 needs to be done. It was a busy > > week-end :) > > > > We should be almost there, I believe I had addressed in > > sthib

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on lun. 19 mars 2018 02:51:22 +0100, wrote: > - Fixing GNU Coding Style, notably first line of files. Could people have a look in the libpthread repository? Most probably, for a lot of these files, one can just take the first line of the corresponding nptl file and put "Hurd versi

Re: Upstreaming the glibc Hurd port

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: - Two patches pending comments on libc-alpha: [PATCH] hurd: Initialize TLS and li

Re: Upstreaming the glibc Hurd port

Hello, Joseph Myers, on jeu. 18 janv. 2018 14:03:18 +, wrote: > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > > Before Hurd support is fully integrated in glibc, I'd encourage having a > > > branch *in the glibc repository* that contains such support, so we can > > > more readily see wh

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 25 janv. 2018 16:12:48 +, wrote: > do you really need [foo] Assume no :) I just imported the source as it is, containing everything that was previously needed to make it buildable both within the hurd repository and the glibc repository. Thanks for listing the issues, t

Re: Upstreaming the glibc Hurd port

Regarding the libpthread / htl code, and getting it ready for inclusion in glibc master: Obviously my general coding style comments at apply equally to this code. Apart from that: * Remove htl/ChangeLog. We don't have subdirectory

Re: Upstreaming the glibc Hurd port

On Thu, 25 Jan 2018, Samuel Thibault wrote: > Samuel Thibault, on mer. 24 janv. 2018 02:27:26 +0100, wrote: > > Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote: > > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +, wrote: > > > > and indicate whether the above errors indicate prob

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on mer. 24 janv. 2018 02:27:26 +0100, wrote: > Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote: > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +, wrote: > > > and indicate whether the above errors indicate problems with these > > > changes, or simply incompletene

Re: Upstreaming the glibc Hurd port

On Wed, 24 Jan 2018, Samuel Thibault wrote: > Hello, > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +, wrote: > > Could Hurd people review how this handles building for Hurd, > > Yes, it looks good. Thanks, I've committed it to master. > > and indicate whether the above errors indicate p

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote: > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +, wrote: > > and indicate whether the above errors indicate problems with these > > changes, or simply incompleteness of the build support on the > > sthibaul/hurd-builds branch at pres

Re: Upstreaming the glibc Hurd port

Hello, Joseph Myers, on ven. 19 janv. 2018 17:23:29 +, wrote: > Could Hurd people review how this handles building for Hurd, Yes, it looks good. > and indicate whether the above errors indicate problems with these > changes, or simply incompleteness of the build support on the > sthibaul/hur

Re: Upstreaming the glibc Hurd port

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

Re: Upstreaming the glibc Hurd port

On Fri, 19 Jan 2018, Zack Weinberg wrote: > 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

Re: Upstreaming the glibc Hurd port

Joseph Myers, on ven. 19 janv. 2018 17:50:19 +, wrote: > Incidentally, building for GNU/Linux (at least x86_64) is broken on the > sthibaul/hurd-builds branch (I suspect, based on the error messages, that > "t2.26/sched_param" was responsible, but didn't verify that). sched_param is very pro

Re: Upstreaming the glibc Hurd port

Incidentally, building for GNU/Linux (at least x86_64) is broken on the sthibaul/hurd-builds branch (I suspect, based on the error messages, that "t2.26/sched_param" was responsible, but didn't verify that). (I was testing to make sure my build-many-glibcs.py changes didn't affect GNU/Linux bu

Re: Upstreaming the glibc Hurd port

Joseph Myers, on ven. 19 janv. 2018 17:23:29 +, wrote: > or simply incompleteness of the build support on the > sthibaul/hurd-builds branch at present? It's still incomplete, yes. Samuel

Re: Upstreaming the glibc Hurd port

On Fri, 19 Jan 2018, Thomas Schwinge wrote: > Hi Joseph! > > On Fri, 19 Jan 2018 00:34:42 +, Joseph Myers > wrote: > > On Fri, 19 Jan 2018, Samuel Thibault wrote: > > > > > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote: > > > > Thanks for the changes pushed to sthibaul/hurd-bui

Re: Upstreaming the glibc Hurd port

On Fri, 19 Jan 2018, Thomas Schwinge wrote: > Hi! > > On Fri, 19 Jan 2018 13:08:01 +, Joseph Myers > wrote: > > On Fri, 19 Jan 2018, Thomas Schwinge wrote: > > > > [build-many-glibcs.py] > > > Do you have advice on versions to use of mig / gnumach / hurd? > > > > Currently, build-many-gli

Re: Upstreaming the glibc Hurd port

Hi! On Fri, 19 Jan 2018 13:08:01 +, Joseph Myers wrote: > On Fri, 19 Jan 2018, Thomas Schwinge wrote: > > > [build-many-glibcs.py] > Do you have advice on versions to use of mig / gnumach / hurd? > > Currently, build-many-glibcs.py uses (by default) release versions of most > components o

Re: Upstreaming the glibc Hurd port

On Fri, 19 Jan 2018, Thomas Schwinge wrote: > > - if the branch has sources that build for Hurd, I should have some chance > > of using > > https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/cross-gnu?h=cross-gnu/master > > > > to figure out how to do the Hurd-specific pieces that will

Re: Upstreaming the glibc Hurd port

Hello, On 01/19/18 12:10, Thomas Schwinge wrote: > Beware that this script is from many years ago -- from times before my > dear CodeSourcery colleagues taught be how to ;-) properly build > cross-compilers. But yes, cross-gnu did work back then. > > Another thing to look into nowadays is David'

Re: Upstreaming the glibc Hurd port

Hi Joseph! On Fri, 19 Jan 2018 00:34:42 +, Joseph Myers wrote: > On Fri, 19 Jan 2018, Samuel Thibault wrote: > > > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote: > > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise > > > there will be more to get it int

Re: Upstreaming the glibc Hurd port

On Fri, 19 Jan 2018, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote: > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise > > there will be more to get it into a buildable state, e.g. the actual > > libpthread implementation). > > What

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote: > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise > there will be more to get it into a buildable state, e.g. the actual > libpthread implementation). What I have pushed is basically only missing the libpthread im

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > That's why I meant work is needed to sort out what we want to show > people. Which takes triaging time, back to square 0. I sent to the > bug-hurd list the list of patches which was enough at some point to get > glibc buildable, that's what should be w

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 16:47:55 +, wrote: > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > Not all of them are necessary for managing to build glibc. Some of them > > are just hacking, others are perhaps almost ready to commit, just > > missing changelogs & formatting. That's the

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 16:47:55 +, wrote: > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +, wrote: > > > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > > Coding standards can be worked on by anybody, this is really something

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +, wrote: > > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > Coding standards can be worked on by anybody, this is really something > > > that bug-hurd people can unload us from. > > > > Which is als

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +, wrote: > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > Coding standards can be worked on by anybody, this is really something > > that bug-hurd people can unload us from. > > Which is also something that having a branch with the patches is help

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > Coding standards can be worked on by anybody, this is really something > that bug-hurd people can unload us from. Which is also something that having a branch with the patches is helpful for - it allows glibc people to look over them and point out co

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +, wrote: > > (I'd also suggest that it *not* use a top-level directory called > > simply "libpthread" or similar without mention of Hurd, as that would > > be too confusing to people looking at the sour

Re: Upstreaming the glibc Hurd port

Thomas Schwinge, on jeu. 18 janv. 2018 15:22:09 +0100, wrote: > Despite my good intentions, in the past year (or even longer...) I failed > to allocate sufficient time to do any substantial work on the Hurd side, > but I'll now allocate time to at least help with... > > On Thu, 18 Jan 2018 14:57:5

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +, wrote: > (I'd also suggest that it *not* use a top-level directory called > simply "libpthread" or similar without mention of Hurd, as that would > be too confusing to people looking at the source tree for pthreads for > other platforms.) Sure :)

Re: Upstreaming the glibc Hurd port

Thomas Schwinge, on jeu. 18 janv. 2018 15:22:09 +0100, wrote: > > I can pile-commit what we currently have, with all the XXXs, FIXMEs, > > etc., if that can help the glibc side. > > I'm not sure if that's a useful thing to spend time on, right now. I > think it'll be better if we first integrate

Re: Upstreaming the glibc Hurd port

Hi! Despite my good intentions, in the past year (or even longer...) I failed to allocate sufficient time to do any substantial work on the Hurd side, but I'll now allocate time to at least help with... On Thu, 18 Jan 2018 14:57:58 +0100, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv.

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > > Before Hurd support is fully integrated in glibc, I'd encourage having a > > branch *in the glibc repository* that contains such support, so we can > > more readily see what the changes yet to be merged are (and possibly > > comment on issues that

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 13:52:32 +, wrote: > Incidentally, Samuel did post the Hurd TLS support three years ago > . Roland's > review comments should of course be considered, Yes, it has been on my TODO list for as long

Re: Upstreaming the glibc Hurd port

On 01/18/2018 01:45 PM, Samuel Thibault wrote: Florian Weimer, on jeu. 18 janv. 2018 13:39:51 +0100, wrote: Is it just a matter of someone doing the work of upstreaming all the existing patches? It's mostly that, yes. Good to know, thanks. The question is how we can do this incrementally (s

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +, wrote: > Please note (as a reminder from past discussions) that the Hurd libpthread > will need to be included as part of glibc, much like NPTL is a > fully-integrated part of glibc - not a separate package (support for > add-ons has been remov

Re: Upstreaming the glibc Hurd port

Incidentally, Samuel did post the Hurd TLS support three years ago . Roland's review comments should of course be considered, though the current Hurd port maintainers are free to decide they disagree with particular aspects of those c

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on jeu. 18 janv. 2018 14:40:37 +0100, wrote: > I came up with the following list of patches They are usually more or less named like the corresponding topgit branch in our glibc repo. The .topmsg file can be use to track what work has been done on the patch (checking formatting, c

Re: Upstreaming the glibc Hurd port

Please note (as a reminder from past discussions) that the Hurd libpthread will need to be included as part of glibc, much like NPTL is a fully-integrated part of glibc - not a separate package (support for add-ons has been removed from glibc). (I'd also suggest that it *not* use a top-level d

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on jeu. 18 janv. 2018 13:45:37 +0100, wrote: > Unless bug-hurd people actually help me with it. FI, in my previous glibc upstream build attemps, I came up with the following list of patches which are required for upstream glibc to build at all. Most of them don't have changelog, h

Re: Upstreaming the glibc Hurd port

Florian Weimer, on jeu. 18 janv. 2018 13:39:51 +0100, wrote: > Is it just a matter of someone doing the work of upstreaming all the > existing patches? It's mostly that, yes. > If we cannot resolve this is in the coming months, I think we should > seriously consider a removal of the Hurd port, I'