[hurd,commited] hurd: Fix build without NO_HIDDEN
Commit Message
* 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.
---
ChangeLog | 14 ++++++++++++++
posix/sched_primax.c | 1 +
posix/sched_primin.c | 1 +
sysdeps/mach/hurd/dl-sysdep.c | 13 +++++++++++++
sysdeps/mach/hurd/mmap.c | 1 +
sysdeps/mach/hurd/mmap64.c | 1 +
sysdeps/mach/mprotect.c | 1 +
sysdeps/mach/munmap.c | 1 +
8 files changed, 33 insertions(+)
Comments
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
@@ -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.
@@ -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)
@@ -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)
@@ -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
@@ -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)
@@ -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)
@@ -47,4 +47,5 @@ __mprotect (void *addr, size_t len, int prot)
}
return 0;
}
+libc_hidden_def (__mprotect)
weak_alias (__mprotect, mprotect)
@@ -43,4 +43,5 @@ __munmap (void *addr, size_t len)
return 0;
}
+libc_hidden_def (__munmap)
weak_alias (__munmap, munmap)