| Message ID | 20170911233614.26389-1-samuel.thibault@ens-lyon.org |
|---|---|
| State | New |
| Headers | show |
| Series | [hurd,commited] hurd: Fix build without NO_HIDDEN | expand |
On 12/09/2017 17:36, Samuel Thibault wrote: > Adhemerval Zanella, on mar. 12 sept. 2017 17:34:51 -0300, wrote: >> Samuel, since you spent time in a lot of patches to fix Hurd build, >> wouldn't be better if you could add hurd build support on >> build-many-glibcs.py? > > Unfortunately, we are still far from having something buildable. I'm > here just keeping up with the newer versions, but there are patches > needed (e.g. for TLS) which are not included yet and need care. So currently you can't really build glibc master for hurd, is it correct? > >> I do not know if it is possible to cross-compiling hurd on Linux, > > It is, but that needs a cross-toolchain which is really not trivial :) Right, but how currently are you actually testing your changes? Do we need an old dated toolchain? If so, is there any option to actually integrate it on build-many-glibcs.py? > >> but I think at least a native build could be useful so generic changes >> could be checked against Hurd as well. > > Yep, ideally :) > > Samuel > PS: I am CC'ing libc-alpha because it was my initial intent.
Adhemerval Zanella, on mar. 12 sept. 2017 18:51:08 -0300, wrote: > On 12/09/2017 17:36, Samuel Thibault wrote: > > Adhemerval Zanella, on mar. 12 sept. 2017 17:34:51 -0300, wrote: > >> Samuel, since you spent time in a lot of patches to fix Hurd build, > >> wouldn't be better if you could add hurd build support on > >> build-many-glibcs.py? > > > > Unfortunately, we are still far from having something buildable. I'm > > here just keeping up with the newer versions, but there are patches > > needed (e.g. for TLS) which are not included yet and need care. > > So currently you can't really build glibc master for hurd, is it > correct? Yes, some patches are needed. > >> I do not know if it is possible to cross-compiling hurd on Linux, > > > > It is, but that needs a cross-toolchain which is really not trivial :) > > Right, but how currently are you actually testing your changes? I test with the additional needed patches in. They usually don't interfere with the changes. If they do, then they get queue behind those missing patches. > Do we need an old dated toolchain? No, we use current binutils & gcc-6 etc. (probably gcc-7 will be fine, it was just not tested yet in Debian). > >> but I think at least a native build could be useful so generic changes > >> could be checked against Hurd as well. > > > > Yep, ideally :) > > PS: I am CC'ing libc-alpha because it was my initial intent. Ok :) samuel
On Tue, 12 Sep 2017, Adhemerval Zanella wrote: > Right, but how currently are you actually testing your changes? Do we > need an old dated toolchain? If so, is there any option to actually > integrate it on build-many-glibcs.py? https://www.gnu.org/software/hurd/toolchain/cross-gnu.html describes a script for building a cross toolchain for Hurd. I don't know how current it is. Yes, we should have such support in build-many-glibcs.py for checking out and building whatever's relevant from MIG / GNU Mach / Hurd / Hurd libpthread and building glibc for Hurd. I think that makes sense even without functional Hurd support in glibc; it will just fail in all builds (like existing broken configurations) and then once the Hurd support in glibc is fixed, we'll see it change from FAIL to PASS in the results from the bots. (Should Hurd libpthread actually be part of glibc rather than a separate package?)
Joseph Myers, on mar. 12 sept. 2017 23:14:54 +0000, wrote: > (Should Hurd libpthread actually be part of glibc rather than a separate > package?) It is actually currently meant to be built as a glibc add-on. Samuel
On Wed, 13 Sep 2017, Samuel Thibault wrote: > Joseph Myers, on mar. 12 sept. 2017 23:14:54 +0000, wrote: > > (Should Hurd libpthread actually be part of glibc rather than a separate > > package?) > > It is actually currently meant to be built as a glibc add-on. However: (a) NPTL used to be an add-on, but isn't any more. That seems analogous to Hurd libpthread. (b) The only add-on in tree is thus libidn. I'm not aware of any out-of-tree add-ons in widespread use. Thus, the utility of having the add-on mechanism at all (rather than building libidn unconditionally, or based on a normal configure option with some mechanism to use an external libidn as an alternative) is dubious. (c) If you work on the basis that Hurd libpthread should end up in the glibc repository (and stop using the add-on mechanism, though stopping using that mechanism is separate from becoming part of the glibc repository, as long as the mechanism still exists), that simplifies the build process needing adding to build-many-glibcs.py, as there's one fewer component to check out.
Joseph Myers, on mar. 12 sept. 2017 23:44:15 +0000, wrote: > On Wed, 13 Sep 2017, Samuel Thibault wrote: > > > Joseph Myers, on mar. 12 sept. 2017 23:14:54 +0000, wrote: > > > (Should Hurd libpthread actually be part of glibc rather than a separate > > > package?) > > > > It is actually currently meant to be built as a glibc add-on. > > However: Sure, sure, in an ideal world I'd have an infinite amount of time to fix all of that stuff. Samuel
diff --git a/ChangeLog b/ChangeLog index a9b6460090..7f8432cb37 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,17 @@ +2017-09-12 Samuel Thibault <samuel.thibault@ens-lyon.org> + + * posix/sched_primax.c (__sched_get_priority_max): Add + libc_hidden_def. + * posix/sched_primin.c (__sched_get_priority_min): Likewise. + * sysdeps/mach/hurd/mmap.c (__mmap): Likewise. + * sysdeps/mach/hurd/mmap64.c (__mmap64): Likewise. + * sysdeps/mach/hurd/mprotect.c (__mprotect): Likewise. + * sysdeps/mach/hurd/munmap.c (__munmap): Likewise. + * sysdeps/mach/hurd/dl-sysdep.c (__GI___getpid, + __GI___strtoul_internal, __GI_____strtoul_internal, __GI___chk_fail, + __GI___fortify_fail, __GI___assert_fail, __GI___assert_perror_fail): + Add aliases. + 2017-09-11 Joseph Myers <joseph@codesourcery.com> * sysdeps/generic/libm-alias-float.h: New file. diff --git a/posix/sched_primax.c b/posix/sched_primax.c index 6f40b83f6c..ed711c7317 100644 --- a/posix/sched_primax.c +++ b/posix/sched_primax.c @@ -26,6 +26,7 @@ __sched_get_priority_max (int algorithm) __set_errno (ENOSYS); return -1; } +libc_hidden_def (__sched_get_priority_max) stub_warning (sched_get_priority_max) weak_alias (__sched_get_priority_max, sched_get_priority_max) diff --git a/posix/sched_primin.c b/posix/sched_primin.c index 7e38a7cc6b..149b994406 100644 --- a/posix/sched_primin.c +++ b/posix/sched_primin.c @@ -26,6 +26,7 @@ __sched_get_priority_min (int algorithm) __set_errno (ENOSYS); return -1; } +libc_hidden_def (__sched_get_priority_min) stub_warning (sched_get_priority_min) weak_alias (__sched_get_priority_min, sched_get_priority_min) diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c index 517e4d62cc..8a8ac76efa 100644 --- a/sysdeps/mach/hurd/dl-sysdep.c +++ b/sysdeps/mach/hurd/dl-sysdep.c @@ -577,6 +577,10 @@ __getpid (void) return pid; } +/* We need this alias to satisfy references from libc_pic.a objects + that were affected by the libc_hidden_proto declaration for __getpid. */ +strong_alias (__getpid, __GI___getpid) + /* This is called only in some strange cases trying to guess a value for $ORIGIN for the executable. The dynamic linker copes with getcwd failing (dl-object.c), and it's too much hassle to include @@ -611,6 +615,11 @@ __strtoul_internal (const char *nptr, char **endptr, int base, int group) return _dl_strtoul (nptr, endptr); } +/* We need this alias to satisfy references from libc_pic.a objects + that were affected by the libc_hidden_proto declaration for __strtoul_internal. */ +strong_alias (__strtoul_internal, __GI___strtoul_internal) +strong_alias (__strtoul_internal, __GI_____strtoul_internal) + void weak_function attribute_hidden _exit (int status) { @@ -649,6 +658,10 @@ abort (void) /* We need this alias to satisfy references from libc_pic.a objects that were affected by the libc_hidden_proto declaration for abort. */ strong_alias (abort, __GI_abort) +strong_alias (abort, __GI___chk_fail) +strong_alias (abort, __GI___fortify_fail) +strong_alias (abort, __GI___assert_fail) +strong_alias (abort, __GI___assert_perror_fail) /* This function is called by interruptible RPC stubs. For initial dynamic linking, just use the normal mach_msg. Since this defn is diff --git a/sysdeps/mach/hurd/mmap.c b/sysdeps/mach/hurd/mmap.c index 72706c3332..a6b4e8bf9e 100644 --- a/sysdeps/mach/hurd/mmap.c +++ b/sysdeps/mach/hurd/mmap.c @@ -185,4 +185,5 @@ __mmap (void *addr, size_t len, int prot, int flags, int fd, off_t offset) return (void *) mapaddr; } +libc_hidden_def (__mmap) weak_alias (__mmap, mmap) diff --git a/sysdeps/mach/hurd/mmap64.c b/sysdeps/mach/hurd/mmap64.c index 282b7525c8..1547e856b7 100644 --- a/sysdeps/mach/hurd/mmap64.c +++ b/sysdeps/mach/hurd/mmap64.c @@ -44,4 +44,5 @@ __mmap64 (void *addr, size_t len, int prot, int flags, int fd, return __mmap (addr, len, prot, flags, fd, small_offset); } +libc_hidden_def (__mmap64) weak_alias (__mmap64, mmap64) diff --git a/sysdeps/mach/mprotect.c b/sysdeps/mach/mprotect.c index 84a72850ac..680905703d 100644 --- a/sysdeps/mach/mprotect.c +++ b/sysdeps/mach/mprotect.c @@ -47,4 +47,5 @@ __mprotect (void *addr, size_t len, int prot) } return 0; } +libc_hidden_def (__mprotect) weak_alias (__mprotect, mprotect) diff --git a/sysdeps/mach/munmap.c b/sysdeps/mach/munmap.c index 4a98613baf..5ba414ba05 100644 --- a/sysdeps/mach/munmap.c +++ b/sysdeps/mach/munmap.c @@ -43,4 +43,5 @@ __munmap (void *addr, size_t len) return 0; } +libc_hidden_def (__munmap) weak_alias (__munmap, munmap)