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

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

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 >

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

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

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

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

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

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

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

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

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

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 =

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

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:

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

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

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

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

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,

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

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

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,

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

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

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 >

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

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

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

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

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

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

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

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

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.

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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,