Re: [PATCH] Hurd: Enable ifunc by default

On Wed, 13 Jan 2021, Thomas Schwinge wrote: > Hi! > > Thanks (and sorry for the delay), pushed "Hurd: Enable ifunc by default" > to master branch in commit e9cb89b936f831a02318d45fc4ddb06f7be55ae4, and > cherry-picked into releases/gcc-10 branch in commit > 92b131491c22eb4e4b663d226e9d97f1fd69306

Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too

This commit broke the glibc build for i686-gnu. There are errors of the form: In file included from ../hurd/hurd/threadvar.h:23, from ../sysdeps/mach/hurd/mig-reply.c:20: ../sysdeps/mach/hurd/i386/tls.h:104:11: fatal error: mach/i386/mach_i386.h: No such file or directory 104

Re: [PATCH v3 0/6] The remaining x86_64-gnu patches

On Sat, 29 Apr 2023, Sergey Bugaev via Libc-alpha wrote: > If these patches are pushed, it should be possible for anyone to build > x86_64-gnu glibc just out of Git master, without having to dig through > the mailing list archive for uncommited patches. In that case I think there should be a patc

Re: [PATCH v3 0/6] The remaining x86_64-gnu patches

On Tue, 2 May 2023, Samuel Thibault via Libc-alpha wrote: > Joseph Myers, le mar. 02 mai 2023 14:03:16 +, a ecrit: > > On Sat, 29 Apr 2023, Sergey Bugaev via Libc-alpha wrote: > > > > > If these patches are pushed, it should be possible for anyone to build > >

Re: [PATCH v3 0/6] The remaining x86_64-gnu patches

On Tue, 2 May 2023, Sergey Bugaev via Libc-alpha wrote: > It would also probably make sense to mention my other changes, of > which there have been many, in the NEWS (would a simple "many fixes > and improvements in the Hurd port" suffice?) That may well be an appropriate way to describe them (if

Re: [hurd,commited] hurd: Enable x86_64 build script

I'm observing that build-many-glibcs.py runs can end up with modifications to the source directory (which later cause problems with updating the glibc checkout): diff --git a/sysdeps/mach/hurd/bits/errno.h b/sysdeps/mach/hurd/bits/errno.h index 069865189f..3b6363568d 100644 --- a/sysdeps/mach/hu

Re: [RFC PATCH 10/10] hurd: Regenerate errno.h

On Wed, 17 May 2023, Sergey Bugaev via Libc-alpha wrote: > Signed-off-by: Sergey Bugaev > --- > My build keeps insisting that stdc-predef.h should be next to sysdeps and > sys/cdefs.h; maybe it's right? If not, how do I stop it from changing? I suggest changing the generator code not to put this

Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self

I suspect this of causing linknamespace test failures: Contents of conform/POSIX2008/pthread.h/linknamespace.out: [initial] pthread_create -> [libpthread.a(pt-create.o)] __pthread_setup -> [libpthread.a(pt-setup.o)] hurd_thread_self (On x86_64 there's also a localplt test failure: "Extra PLT re

Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self

On Thu, 18 May 2023, Sergey Bugaev via Libc-alpha wrote: > Hello, > > On Thu, May 18, 2023 at 9:55 PM Joseph Myers wrote: > > > > I suspect this of causing linknamespace test failures: > > > > Contents of conform/POSIX2008/pthread.h/linknamespace.out:

Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self

On Fri, 19 May 2023, Sergey Bugaev via Libc-alpha wrote: > 'foo' is a public symbol, to be used by the user, and also > interposable by the user. Always called via PLT (except from inside > the user's code when redefined inside the executable, in which case > the compiler/linker will see that no P

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

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

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

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 to

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

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

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 imple

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

On Fri, 19 Jan 2018, Thomas Schwinge wrote: > Hi! > > On Fri, 19 Jan 2018 13:08:01 +0000, 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

Re: Upstreaming the glibc Hurd port

On Fri, 19 Jan 2018, Thomas Schwinge wrote: > Hi Joseph! > > On Fri, 19 Jan 2018 00:34:42 +0000, Joseph Myers > wrote: > > On Fri, 19 Jan 2018, Samuel Thibault wrote: > > > > > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote: > > > > T

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

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 t

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 w

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 whe

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

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

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

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

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

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

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

Re: [RFC PATCH 00/23] aarch64-gnu port

On Wed, 3 Jan 2024, Sergey Bugaev wrote: > To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), > and GNU Mach headers for AArch64. I have posted the patches for > binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches > are required to build aarch64-gnu-mig. > The