[hurd,commited] hurd: Fix build without NO_HIDDEN

Message ID 20170911233614.26389-1-samuel.thibault@ens-lyon.org
State New
Headers show
Series
  • [hurd,commited] hurd: Fix build without NO_HIDDEN
Related show

Commit Message

Samuel Thibault Sept. 11, 2017, 11:36 p.m.
* 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

Adhemerval Zanella Sept. 12, 2017, 9:51 p.m. | #1
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.
Samuel Thibault Sept. 12, 2017, 9:56 p.m. | #2
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
Joseph Myers Sept. 12, 2017, 11:14 p.m. | #3
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?)
Samuel Thibault Sept. 12, 2017, 11:37 p.m. | #4
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
Joseph Myers Sept. 12, 2017, 11:44 p.m. | #5
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.
Samuel Thibault Sept. 12, 2017, 11:52 p.m. | #6
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

Patch

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)