Bug#584819: gcc-4.5: FTBFS on hurd-i386
Package: gcc-4.5
Version: 4.5-20100202-1
Severity: important
Tags: patch
Hello,
Here is an update of the hurd patches for gcc-4.5 to fix FTBFS. The
patch removes merged changes from hurd-changes.diff, and moves
the dyn_load.c change from it to the rest of boehm-gc fixes in
hurd-pthread.diff, so that hurd-changes.diff only contain long-term
changes (GNU /include -> Debian GNU /usr/include)
Could you apply it?
Thanks,
Samuel
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.34 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gcc-4.5 depends on:
ii binutils 2.20.1-9 The GNU assembler, linker and bina
ii cpp-4.5 4.5-20100202-1 The GNU C preprocessor
ii gcc-4.5-base 4.5-20100202-1 The GNU Compiler Collection (base
ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
ii libcloog-ppl0 0.15.9-1 the Chunky Loop Generator (runtime
ii libelfg0 0.8.13-1 an ELF object file access library
ii libgcc1 1:4.5-20100202-1 GCC support library
ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library
ii libgmpxx4ldbl 2:4.3.2+dfsg-1 Multiprecision arithmetic library
ii libgomp1 4.5-20100202-1 GCC OpenMP (GOMP) support library
ii libmpc2 0.8.1-1 multiple precision complex floatin
ii libmpfr1ldbl 2.4.2-3 multiple precision floating-point
ii libppl-c2 0.10.2-6 Parma Polyhedra Library (C interfa
ii libppl7 0.10.2-6 Parma Polyhedra Library (runtime l
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages gcc-4.5 recommends:
ii libc6-dev 2.10.2-9 Embedded GNU C Library: Developmen
Versions of packages gcc-4.5 suggests:
ii gcc-4.5-doc 4.5-20100103-1 Documentation for the GNU compiler
pn gcc-4.5-locales <none> (no description available)
pn gcc-4.5-multilib <none> (no description available)
pn libgcc1-dbg <none> (no description available)
pn libgomp1-dbg <none> (no description available)
pn libmudflap0-4.5-dev <none> (no description available)
pn libmudflap0-dbg <none> (no description available)
-- no debconf information
--
Samuel Thibault <samuel.thibault@fnac.net>
<N> un driver qui fait quoi, alors ?
<y> ben pour les bips
<s> pour passer les oops en morse
-+- #ens-mim - vive les rapports de bug -+-
Index: debian/patches/hurd-pthread.diff
===================================================================
--- debian/patches/hurd-pthread.diff (révision 4491)
+++ debian/patches/hurd-pthread.diff (copie de travail)
@@ -1,5 +1,16 @@
# Fix pthread support in a/src/boehm-gc
+--- a/src/boehm-gc/dyn_load.c
++++ b/src/boehm-gc/dyn_load.c
+@@ -26,7 +26,7 @@
+ * None of this is safe with dlclose and incremental collection.
+ * But then not much of anything is safe in the presence of dlclose.
+ */
+-#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE)
++#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) && !defined(_GNU_SOURCE)
+ /* Can't test LINUX, since this must be define before other includes */
+ # define _GNU_SOURCE
+ #endif
--- a/src/boehm-gc/pthread_support.c.orig 2009-02-07 22:27:11.828527000 +0000
+++ b/src/boehm-gc/pthread_support.c 2009-02-07 22:27:18.279505000 +0000
@@ -885,7 +885,7 @@
Index: debian/patches/hurd-changes.diff
===================================================================
--- debian/patches/hurd-changes.diff (révision 4491)
+++ debian/patches/hurd-changes.diff (copie de travail)
@@ -2,48 +2,12 @@
# DP: systems do, and we support both having a /usr -> . symlink, and having a
# DP: /usr directory like the other ports. So this patch should NOT go
# DP: upstream.
-# DP:
-# DP: Define MAXPATHLEN and PATH_MAX.
---
- boehm-gc/dyn_load.c | 2 +-
- gcc/config/gnu.h | 3 ++-
- gcc/config/t-gnu | 2 +-
- gcc/tlink.c | 4 ++++
- 4 files changed, 8 insertions(+), 3 deletions(-)
+ gcc/config/gnu.h | 3 ++-
+ gcc/config/t-gnu | 2 +-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
---- a/src/boehm-gc/dyn_load.c
-+++ b/src/boehm-gc/dyn_load.c
-@@ -26,7 +26,7 @@
- * None of this is safe with dlclose and incremental collection.
- * But then not much of anything is safe in the presence of dlclose.
- */
--#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE)
-+#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) && !defined(_GNU_SOURCE)
- /* Can't test LINUX, since this must be define before other includes */
- # define _GNU_SOURCE
- #endif
---- a/src/gcc/config.gcc 2009-04-26 21:36:36.000000000 +0200
-+++ b/src/gcc/config.gcc 2009-04-26 21:36:53.000000000 +0200
-@@ -3057,7 +3057,7 @@
- i[34567]86-*-darwin* | x86_64-*-darwin*)
- tmake_file="${tmake_file} i386/t-fprules-softfp soft-fp/t-softfp"
- ;;
-- i[34567]86-*-linux* | x86_64-*-linux* | i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu)
-+ i[34567]86-*-linux* | x86_64-*-linux* | i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | i[34567]86-*-gnu*)
- tmake_file="${tmake_file} i386/t-fprules-softfp soft-fp/t-softfp i386/t-linux"
- ;;
- ia64*-*-linux*)
---- a/src/libgcc/config.host 2009-04-27 02:04:10.000000000 +0200
-+++ b/src/libgcc/config.host 2009-04-27 02:04:23.000000000 +0200
-@@ -591,6 +591,7 @@
- case ${host} in
- i[34567]86-*-darwin* | x86_64-*-darwin* | \
- i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
-+ i[34567]86-*-gnu* | \
- i[34567]86-*-linux* | x86_64-*-linux* | \
- i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
- if test "${host_address}" = 32; then
--- a/src/gcc/config/gnu.h
+++ b/src/gcc/config/gnu.h
@@ -30,7 +30,8 @@ along with GCC. If not, see <http://www.gnu.org/licenses/>.
@@ -62,16 +26,3 @@
# In GNU, "/usr" is a four-letter word.
-NATIVE_SYSTEM_HEADER_DIR = /include
+NATIVE_SYSTEM_HEADER_DIR = /usr/include
---- a/src/gcc/tlink.c
-+++ b/src/gcc/tlink.c
-@@ -34,6 +34,10 @@ along with GCC; see the file COPYING3. If not see
-
- #define MAX_ITERATIONS 17
-
-+#ifndef MAXPATHLEN
-+#define MAXPATHLEN 4096
-+#endif
-+
- /* Defined in the automatically-generated underscore.c. */
- extern int prepends_underscore;
-
Reply to: