Skip to contentSkip to conversation

glibc: bump to 2.26

PATCH New Romain Naour 4 participants 15 messages Aug 27, 2017 – Sep 2, 2017

lore
Share & tools
lore
#0 lore raw

cover glibc: bump to 2.26

This series bump glibc to the latest release and allow to remove all local patches!

While testing this new version, some build issues has been dicovered. Two gcc patch are needed to build a toolchain with older compiler (gcc 4.9 to 6.4), gcc 7.2 contain already the fix.

Another C++ namespace change trigger a build issue when the code contain a workaround for math functions:

mesa3d:
"using std::fpclassify;"

https://github.com/mesa3d/mesa/blob/master/include/c99_math.h#L197

jsoncpp:
"#define isfinite std::isfinite"

It's not easy to catch all packages affected by this issue before bumping glibc. So here is the v1 for testing and review.

This series is rebased on master in order to have gcc 7.2 from 2017.08-rc3.
https://git.buildroot.net/buildroot/commit/?id=80546e97fa63e7ce196be648f0fc1eb4e7d711b3

Best regards,
Romain

Romain Naour (7):
package/gcc: fix build issue with glibc 2.26 package/gcc: fix build issue with glibc 2.26 package/mesa3d: fix build issue with glibc >= 2.26 package/jsoncpp: fix build with glibc >= 2.26 package/glibc: needs kernel headers >= 3.10 on powerpc64le package/gcc: enable float128 on powerpc64le with glibc >= 2.26
toolchains
package/glibc: bump to 2.26

 ...t_t-not-struct-ucontext-in-linux-unwind.h.patch | 190 ++++++++++++
 package/gcc/4.9.4/944-sanitizer-linux.patch        |  88 ++++++
 ...t_t-not-struct-ucontext-in-linux-unwind.h.patch | 192 +++++++++++++
 package/gcc/5.4.0/944-sanitizer-linux.patch        |  87 ++++++
 ...t_t-not-struct-ucontext-in-linux-unwind.h.patch | 191 +++++++++++++
 package/gcc/6.4.0/943-sanitizer-linux.patch        |  87 ++++++
 package/gcc/gcc.mk                                 |   8 +
 .../glibc/0001-sh-Fix-building-with-gcc5-6.patch   |  56 ----
 ...00366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch |  35 ---
 ...ject-overly-long-LD_PRELOAD-path-elements.patch | 122 --------
 ...Reject-overly-long-LD_AUDIT-path-elements.patch | 204 -------------
 package/glibc/0005-fix-binutils-2-29-build.patch   |  65 -----
 ...g-IS_IN-libc-guards-to-vectorized-strcspn.patch |  47 ---
 package/glibc/0006-sh4-trap.patch                  | 318 ---------------------
 package/glibc/glibc.hash                           |   2 +-
 package/glibc/glibc.mk                             |   2 +-
 ...001-json_writer-fix-build-with-glibc-2.26.patch |  28 ++
 ...-c99_math-fix-build-issue-with-glibc-2.26.patch |  82 ++++++
 toolchain/toolchain-buildroot/Config.in            |   8 +-
 19 files changed, 962 insertions(+), 850 deletions(-)
 create mode 100644 package/gcc/4.9.4/943-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch
 create mode 100644 package/gcc/4.9.4/944-sanitizer-linux.patch
 create mode 100644 package/gcc/5.4.0/943-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch
 create mode 100644 package/gcc/5.4.0/944-sanitizer-linux.patch
 create mode 100644 package/gcc/6.4.0/942-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch
 create mode 100644 package/gcc/6.4.0/943-sanitizer-linux.patch
 delete mode 100644 package/glibc/0001-sh-Fix-building-with-gcc5-6.patch
 delete mode 100644 package/glibc/0002-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
 delete mode 100644 package/glibc/0003-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
 delete mode 100644 package/glibc/0004-ld.so-Reject-overly-long-LD_AUDIT-path-elements.patch
 delete mode 100644 package/glibc/0005-fix-binutils-2-29-build.patch
 delete mode 100644 package/glibc/0006-i686-Add-missing-IS_IN-libc-guards-to-vectorized-strcspn.patch
 delete mode 100644 package/glibc/0006-sh4-trap.patch
 create mode 100644 package/jsoncpp/0001-json_writer-fix-build-with-glibc-2.26.patch
 create mode 100644 package/mesa3d/0005-c99_math-fix-build-issue-with-glibc-2.26.patch
Signature · 1 line
2.9.5
#1 lore raw

PATCH 1/7 package/gcc: fix build issue with glibc 2.26

In file included from ../../../libgcc/unwind-dw2.c:403:0:
./md-unwind-support.h: In function ??aarch64_fallback_frame_state??:
./md-unwind-support.h:58:21: error: field ??uc?? has incomplete type

     struct ucontext uc;
                     ^~

The fix is already included in gcc 7.2 release [1]. We have to backport it to all older gcc release since it's not included in any stable release yet.

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=14c2f22a1877f6b60a2f7c2f83ffb032759456a6

Cc Thomas Petazzoni <[email protected]>
---
 ...t_t-not-struct-ucontext-in-linux-unwind.h.patch | 190 ++++++++++++++++++++
 ...t_t-not-struct-ucontext-in-linux-unwind.h.patch | 192 +++++++++++++++++++++
 ...t_t-not-struct-ucontext-in-linux-unwind.h.patch | 191 ++++++++++++++++++++
 3 files changed, 573 insertions(+)
 create mode 100644 package/gcc/4.9.4/943-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch
 create mode 100644 package/gcc/5.4.0/943-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch
 create mode 100644 package/gcc/6.4.0/942-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch
package/gcc/4.9.4/943-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch new file +190 -0
new file mode 100644
index 0000000..526346c
@@ -0,0 +1,190 @@
+From b7e85069238c40eae54d0ca03ab6d5470d1815f9 Mon Sep 17 00:00:00 2001
+From: jsm28 <jsm28@138bc75d-0d04-0410-961f-82ee72b054a4>
+Date: Tue, 4 Jul 2017 10:25:10 +0000
+Subject: [PATCH] Use ucontext_t not struct ucontext in linux-unwind.h files.
+
+Current glibc no longer gives the ucontext_t type the tag struct
+ucontext, to conform with POSIX namespace rules.  This requires
+various linux-unwind.h files in libgcc, that were previously using
+struct ucontext, to be fixed to use ucontext_t instead.  This is
+similar to the removal of the struct siginfo tag from siginfo_t some
+years ago.
+
+This patch changes those files to use ucontext_t instead.  As the
+standard name that should be unconditionally safe, so this is not
+restricted to architectures supported by glibc, or conditioned on the
+glibc version.
+
+Tested compilation together with current glibc with glibc's
+build-many-glibcs.py.
+
+	* config/aarch64/linux-unwind.h (aarch64_fallback_frame_state),
+	config/alpha/linux-unwind.h (alpha_fallback_frame_state),
+	config/bfin/linux-unwind.h (bfin_fallback_frame_state),
+	config/i386/linux-unwind.h (x86_64_fallback_frame_state,
+	x86_fallback_frame_state), config/m68k/linux-unwind.h (struct
+	uw_ucontext), config/nios2/linux-unwind.h (struct nios2_ucontext),
+	config/pa/linux-unwind.h (pa32_fallback_frame_state),
+	config/sh/linux-unwind.h (sh_fallback_frame_state),
+	config/tilepro/linux-unwind.h (tile_fallback_frame_state),
+	config/xtensa/linux-unwind.h (xtensa_fallback_frame_state): Use
+	ucontext_t instead of struct ucontext.
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-5-branch at 249958 138bc75d-0d04-0410-961f-82ee72b054a4
+[Romain backport from gcc-5-branch]
+Signed-off-by: Romain Naour <[email protected]>
+---
+ libgcc/config/aarch64/linux-unwind.h | 2 +-
+ libgcc/config/alpha/linux-unwind.h   | 2 +-
+ libgcc/config/bfin/linux-unwind.h    | 2 +-
+ libgcc/config/i386/linux-unwind.h    | 4 ++--
+ libgcc/config/m68k/linux-unwind.h    | 2 +-
+ libgcc/config/nios2/linux-unwind.h   | 2 +-
+ libgcc/config/pa/linux-unwind.h      | 2 +-
+ libgcc/config/sh/linux-unwind.h      | 2 +-
+ libgcc/config/tilepro/linux-unwind.h | 2 +-
+ libgcc/config/xtensa/linux-unwind.h  | 2 +-
+ 10 files changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/libgcc/config/aarch64/linux-unwind.h b/libgcc/config/aarch64/linux-unwind.h
+index 6b5b3cd..d13dc34 100644
+--- a/libgcc/config/aarch64/linux-unwind.h
++++ b/libgcc/config/aarch64/linux-unwind.h
+@@ -52,7 +52,7 @@ aarch64_fallback_frame_state (struct _Unwind_Context *context,
+   struct rt_sigframe
+   {
+     siginfo_t info;
+-    struct ucontext uc;
++    ucontext_t uc;
+   };
+ 
+   struct rt_sigframe *rt_;
+diff --git a/libgcc/config/alpha/linux-unwind.h b/libgcc/config/alpha/linux-unwind.h
+index b5bfd1c..166d3d2 100644
+--- a/libgcc/config/alpha/linux-unwind.h
++++ b/libgcc/config/alpha/linux-unwind.h
+@@ -51,7 +51,7 @@ alpha_fallback_frame_state (struct _Unwind_Context *context,
+     {
+       struct rt_sigframe {
+ 	siginfo_t info;
+-	struct ucontext uc;
++	ucontext_t uc;
+       } *rt_ = context->cfa;
+       sc = &rt_->uc.uc_mcontext;
+     }
+diff --git a/libgcc/config/bfin/linux-unwind.h b/libgcc/config/bfin/linux-unwind.h
+index dc58f0a..8b94568 100644
+--- a/libgcc/config/bfin/linux-unwind.h
++++ b/libgcc/config/bfin/linux-unwind.h
+@@ -52,7 +52,7 @@ bfin_fallback_frame_state (struct _Unwind_Context *context,
+ 	void *puc;
+ 	char retcode[8];
+ 	siginfo_t info;
+-	struct ucontext uc;
++	ucontext_t uc;
+       } *rt_ = context->cfa;
+ 
+       /* The void * cast is necessary to avoid an aliasing warning.
+diff --git a/libgcc/config/i386/linux-unwind.h b/libgcc/config/i386/linux-unwind.h
+index 7986928..a9d621c 100644
+--- a/libgcc/config/i386/linux-unwind.h
++++ b/libgcc/config/i386/linux-unwind.h
+@@ -58,7 +58,7 @@ x86_64_fallback_frame_state (struct _Unwind_Context *context,
+   if (*(unsigned char *)(pc+0) == 0x48
+       && *(unsigned long long *)(pc+1) == RT_SIGRETURN_SYSCALL)
+     {
+-      struct ucontext *uc_ = context->cfa;
++      ucontext_t *uc_ = context->cfa;
+       /* The void * cast is necessary to avoid an aliasing warning.
+          The aliasing warning is correct, but should not be a problem
+          because it does not alias anything.  */
+@@ -138,7 +138,7 @@ x86_fallback_frame_state (struct _Unwind_Context *context,
+ 	siginfo_t *pinfo;
+ 	void *puc;
+ 	siginfo_t info;
+-	struct ucontext uc;
++	ucontext_t uc;
+       } *rt_ = context->cfa;
+       /* The void * cast is necessary to avoid an aliasing warning.
+          The aliasing warning is correct, but should not be a problem
+diff --git a/libgcc/config/m68k/linux-unwind.h b/libgcc/config/m68k/linux-unwind.h
+index 1ba2a0c4..d67767e 100644
+--- a/libgcc/config/m68k/linux-unwind.h
++++ b/libgcc/config/m68k/linux-unwind.h
+@@ -33,7 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+ /* <sys/ucontext.h> is unfortunately broken right now.  */
+ struct uw_ucontext {
+ 	unsigned long	  uc_flags;
+-	struct ucontext  *uc_link;
++	ucontext_t	 *uc_link;
+ 	stack_t		  uc_stack;
+ 	mcontext_t	  uc_mcontext;
+ 	unsigned long	  uc_filler[80];
+diff --git a/libgcc/config/nios2/linux-unwind.h b/libgcc/config/nios2/linux-unwind.h
+index ba4bd80..8978868 100644
+--- a/libgcc/config/nios2/linux-unwind.h
++++ b/libgcc/config/nios2/linux-unwind.h
+@@ -38,7 +38,7 @@ struct nios2_mcontext {
+ 
+ struct nios2_ucontext {
+   unsigned long uc_flags;
+-  struct ucontext *uc_link;
++  ucontext_t *uc_link;
+   stack_t uc_stack;
+   struct nios2_mcontext uc_mcontext;
+   sigset_t uc_sigmask;	/* mask last for extensibility */
+diff --git a/libgcc/config/pa/linux-unwind.h b/libgcc/config/pa/linux-unwind.h
+index 4a3cfff..d2ac437 100644
+--- a/libgcc/config/pa/linux-unwind.h
++++ b/libgcc/config/pa/linux-unwind.h
+@@ -80,7 +80,7 @@ pa32_fallback_frame_state (struct _Unwind_Context *context,
+   struct sigcontext *sc;
+   struct rt_sigframe {
+     siginfo_t info;
+-    struct ucontext uc;
++    ucontext_t uc;
+   } *frame;
+ 
+   /* rt_sigreturn trampoline:
+diff --git a/libgcc/config/sh/linux-unwind.h b/libgcc/config/sh/linux-unwind.h
+index 4875706..671bde7 100644
+--- a/libgcc/config/sh/linux-unwind.h
++++ b/libgcc/config/sh/linux-unwind.h
+@@ -180,7 +180,7 @@ sh_fallback_frame_state (struct _Unwind_Context *context,
+     {
+       struct rt_sigframe {
+ 	siginfo_t info;
+-	struct ucontext uc;
++	ucontext_t uc;
+       } *rt_ = context->cfa;
+       /* The void * cast is necessary to avoid an aliasing warning.
+          The aliasing warning is correct, but should not be a problem
+diff --git a/libgcc/config/tilepro/linux-unwind.h b/libgcc/config/tilepro/linux-unwind.h
+index 27481cf..c24d58c 100644
+--- a/libgcc/config/tilepro/linux-unwind.h
++++ b/libgcc/config/tilepro/linux-unwind.h
+@@ -61,7 +61,7 @@ tile_fallback_frame_state (struct _Unwind_Context *context,
+   struct rt_sigframe {
+     unsigned char save_area[C_ABI_SAVE_AREA_SIZE];
+     siginfo_t info;
+-    struct ucontext uc;
++    ucontext_t uc;
+   } *rt_;
+ 
+   /* Return if this is not a signal handler.  */
+diff --git a/libgcc/config/xtensa/linux-unwind.h b/libgcc/config/xtensa/linux-unwind.h
+index 6832d0b..cb15b4c 100644
+--- a/libgcc/config/xtensa/linux-unwind.h
++++ b/libgcc/config/xtensa/linux-unwind.h
+@@ -63,7 +63,7 @@ xtensa_fallback_frame_state (struct _Unwind_Context *context,
+ 
+   struct rt_sigframe {
+     siginfo_t info;
+-    struct ucontext uc;
++    ucontext_t uc;
+   } *rt_;
+ 
+   /* movi a2, __NR_rt_sigreturn; syscall */
+-- 
+2.9.5
+
package/gcc/5.4.0/943-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch new file +192 -0

192 lines not on this page · raw message

package/gcc/6.4.0/942-Use-ucontext_t-not-struct-ucontext-in-linux-unwind.h.patch new file +191 -0

191 lines not on this page · raw message

Signature · 1 line
2.9.5
#2 lore raw

PATCH 2/7 package/gcc: fix build issue with glibc 2.26

In reply to Romain Naour

../../../../libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: In function ?int __sanitizer::TracerThread(void*)?:
../../../../libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:241:22: error: aggregate ?sigaltstack handler_stack? has incomplete type and cannot be defined
struct sigaltstack handler_stack;

../../../../libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: In function ?int __sanitizer::TracerThread(void*)?:
../../../../libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ?sigaltstack handler_stack? has incomplete type and cannot be defined

   struct sigaltstack handler_stack;
                      ^~~~~~~~~~~~~

The fix is already included in gcc 7.2 release [1]. We have to backport it to all older gcc release since it's not included in any stable release yet.

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=72edc2c02f8b4768ad660f46a1c7e2400c0a8e06

Cc Thomas Petazzoni <[email protected]>
---
 package/gcc/4.9.4/944-sanitizer-linux.patch | 88 +++++++++++++++++++++++++++++
 package/gcc/5.4.0/944-sanitizer-linux.patch | 87 ++++++++++++++++++++++++++++
 package/gcc/6.4.0/943-sanitizer-linux.patch | 87 ++++++++++++++++++++++++++++
 3 files changed, 262 insertions(+)
 create mode 100644 package/gcc/4.9.4/944-sanitizer-linux.patch
 create mode 100644 package/gcc/5.4.0/944-sanitizer-linux.patch
 create mode 100644 package/gcc/6.4.0/943-sanitizer-linux.patch
package/gcc/4.9.4/944-sanitizer-linux.patch new file +88 -0
new file mode 100644
index 0000000..caadf2d
@@ -0,0 +1,88 @@
+From f9a35ba5c150da2e381c4cab01f8f12bcd6af5d2 Mon Sep 17 00:00:00 2001
+From: jakub <jakub@138bc75d-0d04-0410-961f-82ee72b054a4>
+Date: Mon, 17 Jul 2017 19:41:08 +0000
+Subject: [PATCH] 	Backported from mainline 	2017-07-14  Jakub
+ Jelinek  <[email protected]>
+
+	PR sanitizer/81066
+	* sanitizer_common/sanitizer_linux.h: Cherry-pick upstream r307969.
+	* sanitizer_common/sanitizer_linux.cc: Likewise.
+	* sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: Likewise.
+	* tsan/tsan_platform_linux.cc: Likewise.
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch at 250287 138bc75d-0d04-0410-961f-82ee72b054a4
+(cherry picked from commit 72edc2c02f8b4768ad660f46a1c7e2400c0a8e06)
+[Romain backport to 4.9.4]
+Signed-off-by: Romain Naour <[email protected]>
+---
+ libsanitizer/sanitizer_common/sanitizer_linux.cc                      | 3 +--
+ libsanitizer/sanitizer_common/sanitizer_linux.h                       | 4 +---
+ libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc | 2 +-
+ libsanitizer/tsan/tsan_platform_linux.cc                              | 2 +-
+ 4 files changed, 4 insertions(+), 7 deletions(-)
+
+diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc b/libsanitizer/sanitizer_common/sanitizer_linux.cc
+index 69c9c10..8e53673 100644
+--- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
++++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
+@@ -599,8 +599,7 @@ uptr internal_prctl(int option, uptr arg2, uptr arg3, uptr arg4, uptr arg5) {
+   return internal_syscall(__NR_prctl, option, arg2, arg3, arg4, arg5);
+ }
+ 
+-uptr internal_sigaltstack(const struct sigaltstack *ss,
+-                         struct sigaltstack *oss) {
++uptr internal_sigaltstack(const void *ss, void *oss) {
+   return internal_syscall(__NR_sigaltstack, (uptr)ss, (uptr)oss);
+ }
+ 
+diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.h b/libsanitizer/sanitizer_common/sanitizer_linux.h
+index 6422df1..8e111d1 100644
+--- a/libsanitizer/sanitizer_common/sanitizer_linux.h
++++ b/libsanitizer/sanitizer_common/sanitizer_linux.h
+@@ -18,7 +18,6 @@
+ #include "sanitizer_platform_limits_posix.h"
+ 
+ struct link_map;  // Opaque type returned by dlopen().
+-struct sigaltstack;
+ 
+ namespace __sanitizer {
+ // Dirent structure for getdents(). Note that this structure is different from
+@@ -28,8 +27,7 @@ struct linux_dirent;
+ // Syscall wrappers.
+ uptr internal_getdents(fd_t fd, struct linux_dirent *dirp, unsigned int count);
+ uptr internal_prctl(int option, uptr arg2, uptr arg3, uptr arg4, uptr arg5);
+-uptr internal_sigaltstack(const struct sigaltstack* ss,
+-                          struct sigaltstack* oss);
++uptr internal_sigaltstack(const void* ss, void* oss);
+ uptr internal_sigaction(int signum, const __sanitizer_kernel_sigaction_t *act,
+     __sanitizer_kernel_sigaction_t *oldact);
+ uptr internal_sigprocmask(int how, __sanitizer_kernel_sigset_t *set,
+diff --git a/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc b/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
+index 6ee63ec..50c21a3 100644
+--- a/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
++++ b/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
+@@ -238,7 +238,7 @@ static int TracerThread(void* argument) {
+ 
+   // Alternate stack for signal handling.
+   InternalScopedBuffer<char> handler_stack_memory(kHandlerStackSize);
+-  struct sigaltstack handler_stack;
++  stack_t handler_stack;
+   internal_memset(&handler_stack, 0, sizeof(handler_stack));
+   handler_stack.ss_sp = handler_stack_memory.data();
+   handler_stack.ss_size = kHandlerStackSize;
+diff --git a/libsanitizer/tsan/tsan_platform_linux.cc b/libsanitizer/tsan/tsan_platform_linux.cc
+index fe69430..49f5270 100644
+--- a/libsanitizer/tsan/tsan_platform_linux.cc
++++ b/libsanitizer/tsan/tsan_platform_linux.cc
+@@ -351,7 +351,7 @@ bool IsGlobalVar(uptr addr) {
+ // closes within glibc. The code is a pure hack.
+ int ExtractResolvFDs(void *state, int *fds, int nfd) {
+   int cnt = 0;
+-  __res_state *statp = (__res_state*)state;
++  struct __res_state *statp = (struct __res_state*)state;
+   for (int i = 0; i < MAXNS && cnt < nfd; i++) {
+     if (statp->_u._ext.nsaddrs[i] && statp->_u._ext.nssocks[i] != -1)
+       fds[cnt++] = statp->_u._ext.nssocks[i];
+-- 
+2.9.5
+
package/gcc/5.4.0/944-sanitizer-linux.patch new file +87 -0

87 lines not on this page · raw message

package/gcc/6.4.0/943-sanitizer-linux.patch new file +87 -0

87 lines not on this page · raw message

Signature · 1 line
2.9.5
#3 lore raw

PATCH 3/7 package/mesa3d: fix build issue with glibc >= 2.26

In reply to Romain Naour

Issue found while testing glibc 2.26 bump.

---
 ...-c99_math-fix-build-issue-with-glibc-2.26.patch | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 package/mesa3d/0005-c99_math-fix-build-issue-with-glibc-2.26.patch
package/mesa3d/0005-c99_math-fix-build-issue-with-glibc-2.26.patch new file +82 -0
new file mode 100644
index 0000000..55e4fcf
@@ -0,0 +1,82 @@
+From f8ef875d8b5313d8f15f8680dc0c512c10756ea8 Mon Sep 17 00:00:00 2001
+From: Romain Naour <[email protected]>
+Date: Sat, 26 Aug 2017 19:20:56 +0200
+Subject: [PATCH] c99_math: fix build issue with glibc >= 2.26
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The workaround is not required anymore since glibc 2.26 and
+trigger a build issue:
+
+In file included from ../../src/gallium/auxiliary/util/u_math.h:44:0,
+                 from ../../src/mesa/main/macros.h:35,
+                 from glsl_types.cpp:25:
+../../include/c99_math.h:196:12: error: ??std::fpclassify??  was not declared in this scope
+ using std::fpclassify;
+            ^~~~~~~~~~
+../../include/c99_math.h:197:12: error: ??std::isfinite??  was not declared in this scope
+ using std::isfinite;
+            ^~~~~~~~
+../../include/c99_math.h:198:12: error: ??std::isinf??  was not declared in this scope
+ using std::isinf;
+            ^~~~~
+../../include/c99_math.h:199:12: error: ??std::isnan??  was not declared in this scope
+ using std::isnan;
+            ^~~~~
+../../include/c99_math.h:200:12: error: ??std::isnormal??  was not declared in this scope
+ using std::isnormal;
+            ^~~~~~~~
+../../include/c99_math.h:201:12: error: ??std::signbit??  was not declared in this scope
+ using std::signbit;
+            ^~~~~~~
+../../include/c99_math.h:202:12: error: ??std::isgreater??  was not declared in this scope
+ using std::isgreater;
+            ^~~~~~~~~
+../../include/c99_math.h:203:12: error: ??std::isgreaterequal??  was not declared in this scope
+ using std::isgreaterequal;
+            ^~~~~~~~~~~~~~
+../../include/c99_math.h:204:12: error: ??std::isless??  was not declared in this scope
+ using std::isless;
+            ^~~~~~
+../../include/c99_math.h:205:12: error: ??std::islessequal??  was not declared in this scope
+ using std::islessequal;
+            ^~~~~~~~~~~
+../../include/c99_math.h:206:12: error: ??std::islessgreater??  was not declared in this scope
+ using std::islessgreater;
+            ^~~~~~~~~~~~~
+../../include/c99_math.h:207:12: error: ??std::isunordered??  was not declared in this scope
+ using std::isunordered;
+            ^~~~~~~~~~~
+
+Signed-off-by: Romain Naour <[email protected]>
+---
+ include/c99_math.h | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/include/c99_math.h b/include/c99_math.h
+index e906c26..6fd257e 100644
+--- a/include/c99_math.h
++++ b/include/c99_math.h
+@@ -193,6 +193,10 @@ fpclassify(double x)
+ #if __cplusplus >= 201103L && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 23))
+ #include <cmath>
+ 
++/* This workaround is not necessary since Glibc 2.26
++ * https://sourceware.org/git/?p=glibc.git;a=commit;h=2072f5c34ede81dde9e0d953d57a0690a66b0f12
++ */
++#if (__GLIBC__ == 2 && __GLIBC_MINOR__ <= 25)
+ using std::fpclassify;
+ using std::isfinite;
+ using std::isinf;
+@@ -206,6 +210,7 @@ using std::islessequal;
+ using std::islessgreater;
+ using std::isunordered;
+ #endif
++#endif
+ 
+ 
+ #endif /* #define _C99_MATH_H_ */
+-- 
+2.9.5
+
Signature · 1 line
2.9.5
#4 lore raw

PATCH 3/7 package/mesa3d: fix build issue with glibc >= 2.26

Hello,

Quoted 4 lines · Romain Naour

++/* This workaround is not necessary since Glibc 2.26
++ * https://sourceware.org/git/?p=glibc.git;a=commit;h=2072f5c34ede81dde9e0d953d57a0690a66b0f12
++ */
++#if (__GLIBC__ == 2 && __GLIBC_MINOR__ <= 25)

How does this behaves with uClibc and musl? I guess with uClibc it should be fine, because it pretends to be glibc 2.2.

However, musl doesn't define __GLIBC__, so it means that this code, that used to be defined for musl, we no longer be defined. Can check if mesa3d still builds fine with musl after this change ? Or perhaps musl didn't had the original issue ?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#5 lore raw

PATCH 3/7 package/mesa3d: fix build issue with glibc >= 2.26

Hi Thomas,

Le 30/08/2017 ? 22:49, Thomas Petazzoni a ?crit :

Quoted 9 lines

Hello,

Quoted 4 lines · Romain Naour

++/* This workaround is not necessary since Glibc 2.26
++ * https://sourceware.org/git/?p=glibc.git;a=commit;h=2072f5c34ede81dde9e0d953d57a0690a66b0f12
++ */
++#if (__GLIBC__ == 2 && __GLIBC_MINOR__ <= 25)

Quoted 7 lines

How does this behaves with uClibc and musl? I guess with uClibc it should be fine, because it pretends to be glibc 2.2.

However, musl doesn't define __GLIBC__, so it means that this code, that used to be defined for musl, we no longer be defined. Can check if mesa3d still builds fine with musl after this change ? Or perhaps musl didn't had the original issue ?

This code wasn't used with musl toolchain, it's already protected by a __GLIBC__.

Look at the file include/c99_math.h in mesa3d sources.
https://github.com/mesa3d/mesa/blob/master/include/c99_math.h#L193

I wanted to be safe for toolchains using glibc < 2.26. It should be fine with musl toolchain.

Best regards,
Romain

Quoted 3 lines

Thomas

#6 lore raw

PATCH 4/7 package/jsoncpp: fix build with glibc >= 2.26

In reply to Romain Naour

Issue found while testing glibc 2.26 bump.

---
 ...001-json_writer-fix-build-with-glibc-2.26.patch | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 package/jsoncpp/0001-json_writer-fix-build-with-glibc-2.26.patch
package/jsoncpp/0001-json_writer-fix-build-with-glibc-2.26.patch new file +28 -0
new file mode 100644
index 0000000..90acb12
@@ -0,0 +1,28 @@
+From 8b7250335f1a1a4bb46f28846500e11148d78449 Mon Sep 17 00:00:00 2001
+From: Romain Naour <[email protected]>
+Date: Sat, 26 Aug 2017 19:39:03 +0200
+Subject: [PATCH] json_writer: fix build with glibc >= 2.26
+
+Signed-off-by: Romain Naour <[email protected]>
+---
+ src/lib_json/json_writer.cpp | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/lib_json/json_writer.cpp b/src/lib_json/json_writer.cpp
+index 02f1cb1..db61988 100644
+--- a/src/lib_json/json_writer.cpp
++++ b/src/lib_json/json_writer.cpp
+@@ -41,7 +41,9 @@
+ #endif
+ #else
+ #include <cmath>
+-#if !(defined(__QNXNTO__)) // QNX already defines isfinite
++// QNX already defines isfinite
++#if !(defined(__QNXNTO__)) && \
++    (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ <= 25))
+ #define isfinite std::isfinite
+ #endif
+ #endif
+-- 
+2.9.5
+
Signature · 1 line
2.9.5
#7 lore raw

PATCH 5/7 package/glibc: needs kernel headers >= 3.10 on powerpc64le

In reply to Romain Naour

Since glibc 2.26, kernel headers >= 3.10 are needed on powerpc64le [1]. In order to prepare the glibc bump to this version, we don't allow to build a Buildroot toolchain with kernel headers older than 3.10.

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=c2ff5ec13fca1bdd1cd646a0260808386d7bd7ff

Cc Thomas Petazzoni <[email protected]>
---
 toolchain/toolchain-buildroot/Config.in | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
toolchain/toolchain-buildroot/Config.in +7 -1
index f47001f..8ffad61 100644
@@ -45,7 +45,8 @@ config BR2_TOOLCHAIN_BUILDROOT_GLIBC
 	depends on BR2_arm         || BR2_armeb      || BR2_aarch64 || \
 		   BR2_aarch64_be  || BR2_i386       || BR2_mips    || \
 		   BR2_mipsel      || BR2_mips64     || BR2_mips64el|| \
-		   BR2_powerpc     || BR2_powerpc64  || BR2_powerpc64le || \
+		   BR2_powerpc     || BR2_powerpc64  || \
+		   (BR2_powerpc64le && BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10) || \
 		   BR2_sh          || BR2_sparc64    || BR2_x86_64 || \
 		   BR2_microblaze || BR2_nios2
 	depends on BR2_USE_MMU
@@ -65,6 +66,11 @@ comment "glibc needs a toolchain w/ dynamic library, kernel headers >= 3.2"
 	depends on BR2_USE_MMU
 	depends on BR2_STATIC_LIBS || !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
 
+# glibc >= 2.26 require kernel headers >= 3.10 on powerpc64le.
+comment "glibc on powerpc64le needs a toolchain w/ headers >= 3.10"
+	depends on BR2_powerpc64le
+	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
+
 config BR2_TOOLCHAIN_BUILDROOT_MUSL
 	bool "musl"
 	depends on BR2_aarch64	  || BR2_arm     || BR2_armeb     || BR2_i386 || \
Signature · 1 line
2.9.5
#8 lore raw

PATCH 6/7 package/gcc: enable float128 on powerpc64le with glibc >= 2.26 toolchains

In reply to Romain Naour

float128 is now required on powerpc64le with glibc >= 2.26 toolchains.

Fixes:
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/powerpc/powerpc64le
checking if [...]powerpc64le-buildroot-linux-gnu-gcc supports binary128 floating point type... no checking if the target machine is at least POWER8... yes
configure: error: *** binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

In order to prepare the glibc bump to this version, we enable binary128 floating point in gcc. This require at least gcc >= 6.2.

---
 package/gcc/gcc.mk | 8 ++++++++
 1 file changed, 8 insertions(+)
package/gcc/gcc.mk +8 -0
index 49ccccf..54ef70c 100644
@@ -254,6 +254,14 @@ HOST_GCC_COMMON_CONF_OPTS += \
 	--without-long-double-128
 endif
 
+# Since glibc >= 2.26, poerpc64le requires double/long double which
+# requires at least gcc 6.2.
+# See sysdeps/powerpc/powerpc64le/configure.ac
+ifeq ($(BR2_TOOLCHAIN_USES_GLIBC)$(BR2_TOOLCHAIN_GCC_AT_LEAST_6)$(BR2_powerpc64le),yyy)
+HOST_GCC_COMMON_CONF_OPTS += \
+	--with-long-double-128
+endif
+
 HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"'
 ifeq ($(BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS),)
 ifeq ($(call qstrip,$(BR2_GCC_TARGET_CPU_REVISION)),)
Signature · 1 line
2.9.5
#9 lore raw

PATCH 6/7 package/gcc: enable float128 on powerpc64le with glibc >= 2.26 toolchains

Hello,

Quoted 22 lines · Romain Naour

float128 is now required on powerpc64le with glibc >= 2.26 toolchains.

Fixes:
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/powerpc/powerpc64le
checking if [...]powerpc64le-buildroot-linux-gnu-gcc supports binary128 floating point type... no checking if the target machine is at least POWER8... yes
configure: error: *** binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

In order to prepare the glibc bump to this version, we enable binary128 floating point in gcc. This require at least gcc >= 6.2.

---
 package/gcc/gcc.mk | 8 ++++++++
 1 file changed, 8 insertions(+)
package/gcc/gcc.mk +0 -0
index 49ccccf..54ef70c 100644

package/gcc/gcc.mk HOST_GCC_COMMON_CONF_OPTS += \ · line 257

Quoted 4 lines
package/gcc/gcc.mk +1 -0
@@ -254,6 +254,14 @@ HOST_GCC_COMMON_CONF_OPTS += \
 	--without-long-double-128
 endif
 
+# Since glibc >= 2.26, poerpc64le requires double/long double which

Typo: powerpc64le.

package/gcc/gcc.mk HOST_GCC_COMMON_CONF_OPTS += \ · line 260

Quoted 3 lines
package/gcc/gcc.mk +3 -0
+# requires at least gcc 6.2.
+# See sysdeps/powerpc/powerpc64le/configure.ac
+ifeq ($(BR2_TOOLCHAIN_USES_GLIBC)$(BR2_TOOLCHAIN_GCC_AT_LEAST_6)$(BR2_powerpc64le),yyy)

So what happens if I build a gcc 5.x / glibc 2.26 / powerpc64le toolchain ?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#10 lore raw

PATCH 6/7 package/gcc: enable float128 on powerpc64le with glibc >= 2.26 toolchains

Hi Thomas,

Le 30/08/2017 ? 22:51, Thomas Petazzoni a ?crit :

Quoted 32 lines

Hello,

Quoted 22 lines · Romain Naour

float128 is now required on powerpc64le with glibc >= 2.26 toolchains.

Fixes:
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/powerpc/powerpc64le
checking if [...]powerpc64le-buildroot-linux-gnu-gcc supports binary128 floating point type... no checking if the target machine is at least POWER8... yes
configure: error: *** binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

In order to prepare the glibc bump to this version, we enable binary128 floating point in gcc. This require at least gcc >= 6.2.

---
 package/gcc/gcc.mk | 8 ++++++++
 1 file changed, 8 insertions(+)
package/gcc/gcc.mk +0 -0
index 49ccccf..54ef70c 100644

package/gcc/gcc.mk HOST_GCC_COMMON_CONF_OPTS += \ · line 257

Quoted 4 lines
package/gcc/gcc.mk +1 -0
@@ -254,6 +254,14 @@ HOST_GCC_COMMON_CONF_OPTS += \
 	--without-long-double-128
 endif
 
+# Since glibc >= 2.26, poerpc64le requires double/long double which

Typo: powerpc64le.

Quoted 6 lines

package/gcc/gcc.mk HOST_GCC_COMMON_CONF_OPTS += \ · line 260

Quoted 3 lines
package/gcc/gcc.mk +3 -0
+# requires at least gcc 6.2.
+# See sysdeps/powerpc/powerpc64le/configure.ac
+ifeq ($(BR2_TOOLCHAIN_USES_GLIBC)$(BR2_TOOLCHAIN_GCC_AT_LEAST_6)$(BR2_powerpc64le),yyy)

So what happens if I build a gcc 5.x / glibc 2.26 / powerpc64le toolchain ?

As far I understand from the error message, using gcc 5.x with glibc 2.26 on powerpc64le should not be allowed.

I'll fix this.

Thanks for the review.

Best regards,
Romain

Quoted 3 lines

Thomas

#11 lore raw

PATCH 7/7 package/glibc: bump to 2.26

In reply to Romain Naour

Drop upstream patch:

0001-sh-Fix-building-with-gcc5-6.patch
https://sourceware.org/git/?p=glibc.git;a=commit;h=d40dbe722f004f999b589de776f7e57e564dda01

0002-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
https://sourceware.org/git/?p=glibc.git;a=commit;h=f6110a8fee2ca36f8e2d2abecf3cba9fa7b8ea7d

0003-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
https://sourceware.org/git/?p=glibc.git;a=commit;h=6d0ba622891bed9d8394eef1935add53003b12e8

0004-ld.so-Reject-overly-long-LD_AUDIT-path-elements.patch

https://sourceware.org/git/?p=glibc.git;a=commit;h=81b82fb966ffbd94353f793ad17116c6088dedd9

0005-fix-binutils-2-29-build.patch
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff_plain;h=388b4f1a02f3a801965028bbfcd48d905638b797

0006-i686-Add-missing-IS_IN-libc-guards-to-vectorized-strcspn.patch
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff_plain;h=69052a3a95da37169a08f9e59b2cc1808312753c

0006-sh4-trap.patch
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff_plain;h=db3d848e154b00071f4a5e729d5884efad410109

Cc Thomas Petazzoni <[email protected]>
---
 .../glibc/0001-sh-Fix-building-with-gcc5-6.patch   |  56 ----
 ...00366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch |  35 ---
 ...ject-overly-long-LD_PRELOAD-path-elements.patch | 122 --------
 ...Reject-overly-long-LD_AUDIT-path-elements.patch | 204 -------------
 package/glibc/0005-fix-binutils-2-29-build.patch   |  65 -----
 ...g-IS_IN-libc-guards-to-vectorized-strcspn.patch |  47 ---
 package/glibc/0006-sh4-trap.patch                  | 318 ---------------------
 package/glibc/glibc.hash                           |   2 +-
 package/glibc/glibc.mk                             |   2 +-
 9 files changed, 2 insertions(+), 849 deletions(-)
 delete mode 100644 package/glibc/0001-sh-Fix-building-with-gcc5-6.patch
 delete mode 100644 package/glibc/0002-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
 delete mode 100644 package/glibc/0003-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
 delete mode 100644 package/glibc/0004-ld.so-Reject-overly-long-LD_AUDIT-path-elements.patch
 delete mode 100644 package/glibc/0005-fix-binutils-2-29-build.patch
 delete mode 100644 package/glibc/0006-i686-Add-missing-IS_IN-libc-guards-to-vectorized-strcspn.patch
 delete mode 100644 package/glibc/0006-sh4-trap.patch
package/glibc/0001-sh-Fix-building-with-gcc5-6.patch deleted +0 -56
deleted file mode 100644
index fa43bdd..0000000
@@ -1,56 +0,0 @@
-From 3840d4c2add1dd282f5f01fa51720b2d5b8fd8d2 Mon Sep 17 00:00:00 2001
-From: Alexey Neyman <[email protected]>
-Date: Wed, 8 Feb 2017 16:00:57 -0200
-Subject: [PATCH] sh: Fix building with gcc5/6
-
-Build glibc for sh4-unknown-linux-gnu currently fails if one's
-using GCC5/6: in dl-conflict.c, the elf_machine_rela() function
-is called with NULL as its 3rd argument, sym. The implementation
-of that function in sysdeps/sh/dl-machine.h dereferences that pointer:
-
-const Elf32_Sym *const refsym = sym;
-...
-if (map == &GL(dl_rtld_map))
-  value -= map->l_addr + refsym->st_value + reloc->r_addend;
-
-GCC discovers a null pointer dereference, and in accordance with
--fdelete-null-pointer-checks (which is enabled in -O2) replaces this
-code with a trap - which, as SH does not implement a trap pattern in
-GCC, evaluates to an abort() call. This abort() call pulls many more
-objects from libc_nonshared.a, eventually resulting in link failure
-due to multiple definitions for a number of symbols.
-
-As far as I see, the conditional before this code is always false in
-rtld: _dl_resolve_conflicts() is called with main_map as the first
-argument, not GL(_dl_rtld_map), but since that call is in yet another
-compilation unit, GCC does not know about it. Patch that wraps this
-conditional into !defined RESOLVE_CONFLICT_FIND_MAP attached.
-
-	* sysdeps/sh/dl-machine.h (elf_machine_rela): The condition
-	in R_SH_DIR32 case is always false when inlined from
-	dl-conflict.c. Ifdef out to prevent GCC from insertin an
-	abort() call.
-
-[Waldemar: backport of
-https://sourceware.org/git/?p=glibc.git;a=commit;h=d40dbe722f004f999b589de776f7e57e564dda01.]
-Signed-off-by: Waldemar Brodkorb <[email protected]>
----
- sysdeps/sh/dl-machine.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/sysdeps/sh/dl-machine.h b/sysdeps/sh/dl-machine.h
-index 449deea..2b468af 100644
---- a/sysdeps/sh/dl-machine.h
-+++ b/sysdeps/sh/dl-machine.h
-@@ -389,7 +389,7 @@ elf_machine_rela (struct link_map *map, const Elf32_Rela *reloc,
- 	  break;
- 	case R_SH_DIR32:
- 	  {
--#ifndef RTLD_BOOTSTRAP
-+#if !defined RTLD_BOOTSTRAP && !defined RESOLVE_CONFLICT_FIND_MAP
- 	   /* This is defined in rtld.c, but nowhere in the static
- 	      libc.a; make the reference weak so static programs can
- 	      still link.  This declaration cannot be done when
--- 
-2.7.4
-
package/glibc/0002-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch deleted +0 -35
deleted file mode 100644
index d701294..0000000
@@ -1,35 +0,0 @@
-From f6110a8fee2ca36f8e2d2abecf3cba9fa7b8ea7d Mon Sep 17 00:00:00 2001
-From: Florian Weimer <[email protected]>
-Date: Mon, 19 Jun 2017 17:09:55 +0200
-Subject: [PATCH] CVE-2017-1000366: Ignore LD_LIBRARY_PATH for AT_SECURE=1
- programs [BZ #21624]
-
-LD_LIBRARY_PATH can only be used to reorder system search paths, which
-is not useful functionality.
-
-This makes an exploitable unbounded alloca in _dl_init_paths unreachable
-for AT_SECURE=1 programs.
-
-[Peter: Drop ChangeLog modification]
-Signed-off-by: Peter Korsgaard <[email protected]>
----
- elf/rtld.c | 3 ++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
-diff --git a/elf/rtld.c b/elf/rtld.c
-index 2446a87680..2269dbec81 100644
---- a/elf/rtld.c
-+++ b/elf/rtld.c
-@@ -2422,7 +2422,8 @@ process_envvars (enum mode *modep)
- 
- 	case 12:
- 	  /* The library search path.  */
--	  if (memcmp (envline, "LIBRARY_PATH", 12) == 0)
-+	  if (!__libc_enable_secure
-+	      && memcmp (envline, "LIBRARY_PATH", 12) == 0)
- 	    {
- 	      library_path = &envline[13];
- 	      break;
--- 
-2.11.0
-
package/glibc/0003-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch deleted +0 -122

122 lines not on this page · raw message

package/glibc/0004-ld.so-Reject-overly-long-LD_AUDIT-path-elements.patch deleted +0 -204

204 lines not on this page · raw message

package/glibc/0005-fix-binutils-2-29-build.patch deleted +0 -65

65 lines not on this page · raw message

package/glibc/0006-i686-Add-missing-IS_IN-libc-guards-to-vectorized-strcspn.patch deleted +0 -47

47 lines not on this page · raw message

package/glibc/0006-sh4-trap.patch deleted +0 -318

318 lines not on this page · raw message

package/glibc/glibc.hash +1 -1
index daaf014..afae10f 100644
@@ -1,2 +1,2 @@
 # Locally calculated after checking pgp signature (glibc)
-sha256	067bd9bb3390e79aa45911537d13c3721f1d9d3769931a30c2681bfee66f23a0	glibc-2.25.tar.xz
+sha256	e54e0a934cd2bc94429be79da5e9385898d2306b9eaf3c92d5a77af96190f6bd	glibc-2.26.tar.xz
package/glibc/glibc.mk +1 -1
index c9a6579..f5d0282 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-GLIBC_VERSION = 2.25
+GLIBC_VERSION = 2.26
 GLIBC_SITE = $(BR2_GNU_MIRROR)/libc
 GLIBC_SOURCE = glibc-$(GLIBC_VERSION).tar.xz
 GLIBC_SRC_SUBDIR = .
Signature · 1 line
2.9.5
#12 lore raw

cover glibc: bump to 2.26

In reply to Romain Naour

Am Sun, 27 Aug 2017 19:35:59 +0200 schrieb Romain Naour:

Quoted 2 lines

Another C++ namespace change trigger a build issue when the code contain a workaround for math functions:

Hi Romain,

Kodi is also affected by this problem:

/home/buildroot/br8_ffmpeg3_kodi17_github/output/build/kodi-17.4-Krypton/ xbmc/dialogs/GUIDialogExtendedProgressBar.cpp:55:14: error:
'__builtin_isnan' is not a member of 'std'
if (!(std::isnan(fPercentage)))

According to https://github.com/voidlinux/void-packages/
issues/7307#issuecomment-322543154 the problem was solved upstream by these patches: https://sourceware.org/ml/libc-alpha/2017-08/msg00586.html

Voidlinux applied these and other patches from upstream:
https://github.com/voidlinux/void-packages/
commit/728afd17c66644ff41fe018ef2be0c0454944a4f

Regards, Bernd

#13 lore raw

cover glibc: bump to 2.26

Hi Bernd,

Le 28 ao?t 2017 07:20, "Bernd Kuhls" <[email protected]> a ?crit :

Am Sun, 27 Aug 2017 19:35:59 +0200 schrieb Romain Naour:

Quoted 2 lines

Another C++ namespace change trigger a build issue when the code contain a workaround for math functions:

Hi Romain,

Kodi is also affected by this problem:

/home/buildroot/br8_ffmpeg3_kodi17_github/output/build/kodi-17.4-Krypton/ xbmc/dialogs/GUIDialogExtendedProgressBar.cpp:55:14: error:
'__builtin_isnan' is not a member of 'std'
if (!(std::isnan(fPercentage)))

According to https://github.com/voidlinux/void-packages/
issues/7307#issuecomment-322543154 the problem was solved upstream by these patches: https://sourceware.org/ml/libc-alpha/2017-08/msg00586.html

Voidlinux applied these and other patches from upstream:
https://github.com/voidlinux/void-packages/
commit/728afd17c66644ff41fe018ef2be0c0454944a4f

Thanks for testing!

The build issue I reported seems sligly different since using glibc 2.26 stable branch didn't fix mesa and jsoncpp packages.

I'll test again including the backported patch. Also, it would be great if you can test the patch on your side :)

Thanks,
Romain

Regards, Bernd

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170828/fd48efad/attachment.html>

#14 lore raw

cover glibc: bump to 2.26

Hi Bernd,

Le 28/08/2017 ? 09:59, Romain Naour a ?crit :

Quoted 31 lines

Hi Bernd,

Le 28 ao?t 2017 07:20, "Bernd Kuhls" <[email protected] <mailto:[email protected]>> a ?crit :

Am Sun, 27 Aug 2017 19:35:59 +0200 schrieb Romain Naour:

> Another C++ namespace change trigger a build issue when the code contain > a workaround for math functions:

Hi Romain,

Kodi is also affected by this problem:

/home/buildroot/br8_ffmpeg3_kodi17_github/output/build/kodi-17.4-Krypton/ xbmc/dialogs/GUIDialogExtendedProgressBar.cpp:55:14: error:
'__builtin_isnan' is not a member of 'std'
if (!(std::isnan(fPercentage)))

According to https://github.com/voidlinux/void-packages/
<https://github.com/voidlinux/void-packages/>
issues/7307#issuecomment-322543154 the problem was solved upstream by these patches: https://sourceware.org/ml/libc-alpha/2017-08/msg00586.html
<https://sourceware.org/ml/libc-alpha/2017-08/msg00586.html>

Voidlinux applied these and other patches from upstream:
https://github.com/voidlinux/void-packages/
<https://github.com/voidlinux/void-packages/>
commit/728afd17c66644ff41fe018ef2be0c0454944a4f

Quoted 7 lines

Thanks for testing!

The build issue I reported seems sligly different since using glibc 2.26 stable branch didn't fix mesa and jsoncpp packages.

I'll test again including the backported patch. Also, it would be great if you can test the patch on your side :)

I'm testing again with the latest v2.26 version from the git branch but kodi still trigger this issue (event with master).

It seems there is a lot of issues about C++/math with this release... Maybe we want to wait for glibc 2.26.1 ?

Best regards,
Romain

Quoted 14 lines

Thanks,
Romain

Regards, Bernd

_______________________________________________
buildroot mailing list
buildroot at busybox.net <mailto:[email protected]>
http://lists.busybox.net/mailman/listinfo/buildroot
<http://lists.busybox.net/mailman/listinfo/buildroot>