Bug#1073830: gcc-14: Missing build dependency on cargo on hurd-i386
Hello, John Paul Adrian Glaubitz, le mer. 19 juin 2024 13:22:52 +0200, a ecrit: > gcc-14 needs to build-depend on cargo on hurd-i386 to be able to build gccrs > [1]: > >configure: error: cargo is required to build rust More precisely, rs_no_systems was not actually working. And conversely, rust was actually ported to hurd, so we can enable rs on it. The attached patch achieves both. Samuel diff --git a/debian/control b/debian/control index 3ae16fd6..a7e40296 100644 --- a/debian/control +++ b/debian/control @@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.17.14), g++-multilib [amd64 i38 gperf, bison, flex, gettext, nvptx-tools [amd64 arm64 ppc64el], amdgcn-tools-18 [amd64], texinfo, locales-all, sharutils, - procps, gnat-13:native [!sparc !loong64], g++-13:native [!loong64], gnat-13:native [loong64], g++-14:native [loong64], netbase, gdc-13:native [!arc !ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], python3:any, cargo [!hppa !ia64 !m68k !sh4 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], + procps, gnat-13:native [!sparc !loong64], g++-13:native [!loong64], gnat-13:native [loong64], g++-14:native [loong64], netbase, gdc-13:native [!arc !ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], python3:any, cargo [!hppa !ia64 !m68k !sh4 !alpha !hurd-alpha], libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64], lib64z1-dev [i386], unzip , dejagnu , coreutils, chrpath, lsb-release, quilt, time, pkg-config, libgc-dev, diff --git a/debian/rules.defs b/debian/rules.defs index 57a4b8ec..dbaf7f0f 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -1235,7 +1235,7 @@ endif rs_no_cross := yes rs_no_cpus = alpha hppa ia64 m68k sh4 -rs_no_systems := gnu +rs_no_systems := ifneq ($(with_base_only),yes) ifneq ($(separate_lang),yes) @@ -1245,6 +1245,9 @@ endif ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(rs_no_cpus))) with_rs := disabled for arch $(DEB_TARGET_ARCH_CPU) endif +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(rs_no_systems))) + with_rs := disabled for system $(DEB_TARGET_GNU_SYSTEM) +endif ifeq ($(rs_no_cross)-$(DEB_CROSS),yes-yes) with_rs := disabled for cross compiler package endif
Bug#1066932: gcc-14: Please enable m2 on hurd-any
Source: gcc-14 Version: 14-20240303-1 Severity: normal Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Now that upstream has fixed the m2 portability (available in the 20240303 snapshot), could you enable m2 on hurd-any, as the attached patch does? Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. diff --git a/debian/rules.defs b/debian/rules.defs index 928d4e56..44f3f3a0 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -1195,7 +1195,7 @@ ifneq ($(with_base_only),yes) endif endif m2_no_cpus = loong64 powerpc ppc64 sh4 -m2_no_systems = gnu +m2_no_systems = ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif
Bug#1063643: gcc-14: Fix disabling go and m2 according to OS
Samuel Thibault, le sam. 10 févr. 2024 13:07:44 +0100, a ecrit: > There was a typo in rules.defs concerning go_no_systems and > m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS, > while their content is gnu-system-like (kfreebsd-gnu, gnu), and > indeed all other foo_no_systems variables are compared against > DEB_TARGET_GNU_SYSTEM. > > This was making the hurd-i386 build get stuck while building m2, the > attached patch fixes it. Actually in the gcc-14 case there was another typo, updated patch attached. Samuel diff --git a/debian/rules.defs b/debian/rules.defs index 2810b233..6ef02c98 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -989,7 +989,7 @@ endif ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_cpus))) with_go := disabled for arch $(DEB_TARGET_ARCH) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) @@ -1185,11 +1185,11 @@ ifneq ($(with_base_only),yes) endif endif m2_no_cpus = loong64 powerpc ppc64 sh4 -n2_no_systems = gnu +m2_no_systems = gnu ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems))) with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)
Bug#1063643: gcc-14: Fix disabling go and m2 according to OS
Source: gcc-14 Version: 14-20240201-3 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, There was a typo in rules.defs concerning go_no_systems and m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS, while their content is gnu-system-like (kfreebsd-gnu, gnu), and indeed all other foo_no_systems variables are compared against DEB_TARGET_GNU_SYSTEM. This was making the hurd-i386 build get stuck while building m2, the attached patch fixes it. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. diff --git a/debian/rules.defs b/debian/rules.defs index 2810b233..1bb4b96e 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -989,7 +989,7 @@ endif ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_cpus))) with_go := disabled for arch $(DEB_TARGET_ARCH) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) @@ -1189,7 +1189,7 @@ n2_no_systems = gnu ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems))) with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)
Bug#1063642: gcc-13: Fix disabling go and m2 according to OS
Package: gcc-13 Version: 13.2.0-13 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, There was a typo in rules.defs concerning go_no_systems and m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS, while their content is gnu-system-like (kfreebsd-gnu, gnu), and indeed all other foo_no_systems variables are compared against DEB_TARGET_GNU_SYSTEM. This was making the hurd-i386 build get stuck while building m2, the attached patch fixes it. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-13 depends on: ii binutils 2.42-2 ii gcc-13-base 13.2.0-13 ii gcc-13-x86-64-linux-gnu 13.2.0-13 Versions of packages gcc-13 recommends: ii libc6-dev 2.37-15~deb13u1 Versions of packages gcc-13 suggests: ii gcc-13-doc 13.2.0-1 pn gcc-13-locales ii gcc-13-multilib 13.2.0-13 -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. diff --git a/debian/rules.defs b/debian/rules.defs index 8638be92..4fa62c62 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -1019,41 +1019,41 @@ endif go_no_cpus := arc avr hppa loong64 go_no_cpus += m68k # See PR 79281 / PR 83314 go_no_systems := kfreebsd-gnu ifneq (,$(filter $(distrelease),precise)) go_no_cpus = armhf go_no_archs = armhf endif # Debian #969221 go_no_cpus += sh4 go_no_archs += sh4 ifneq ($(with_base_only),yes) ifneq ($(separate_lang),yes) with_go := yes endif endif ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(go_no_cpus))) with_go := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems))) with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_archs))) with_go := disabled for architecture $(DEB_TARGET_ARCH) endif ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes) with_go := disabled for cross compiler package endif ifeq ($(DEB_STAGE)-$(filter libgo, $(with_rtlibs)),rtlibs-) with_go := disabled for rtlibs stage endif with_go := $(call envfilt, go, , , $(with_go)) # Build all packages needed for Go development ifneq (,$(findstring gcc, $(PKGSOURCE))) ifeq ($(with_go),yes) ifeq ($(with_dev),yes) with_godev := yes endif with_libgo := yes @@ -1262,41 +1262,41 @@ endif with_objcxx := $(call envfilt, obj-c++, , c++ objc, $(with_objcxx)) ifeq ($(with_objcxx),yes) enabled_languages += obj-c++ endif # Modula-2 --- m2_no_cross := yes m2_no_cross := no ifneq ($(with_base_only),yes) ifneq ($(separate_lang),yes) with_m2 := yes endif endif m2_no_cpus = loong64 powerpc ppc64 sh4 m2_no_systems = gnu kfreebsd-gnu ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU) endif -ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems))) +ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems))) with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM) endif ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes) with_m2 := disabled for cross compiler package endif ifeq ($(DEB_STAGE)-$(filter libgm2, $(with_rtlibs)),rtlibs-) with_m2 := disabled for rtlibs stage endif ifneq (,$(filter $(distrelease),precise)) with_m2 := disabled for $(distrelease) backport endif #with_m2 := disabled for GCC 13 with_m2 := $(call envfilt, m2, , , $(with_m2)) # Build all packages needed for Modula-2 development ifeq ($(with_m2),yes) ifeq ($(with_dev),yes) with_m2dev := yes endif
Bug#1057004: gcc-13: hurd-amd64 support
Package: gcc-13
Version: 13.2.0-7
Severity: important
Tags: patch
X-Debbugs-Cc: debian-h...@lists.debian.org
User: debian-h...@lists.debian.org
Usertags: hurd
Hello,
The attached patch adds support for hurd-amd64, could you apply it?
The part in hurd-amd64.diff comes from the upstream master commits,
which will thus be included in gcc 14.
The parts in hurd-multiarch.diff and hurd-multilib-multiarch.diff are
for long term, like gcc-multiarch.diff and gcc-multilib-multiarch.diff
for other archs.
Thanks,
Samuel
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'),
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500,
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500,
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gcc-13 depends on:
ii binutils 2.41-7
ii cpp-13 13.2.0-7
ii gcc-13-base13.2.0-7
ii libc6 2.37-12+b1
ii libcc1-0 13.2.0-7
ii libgcc-13-dev 13.2.0-7
ii libgcc-s1 13.2.0-7
ii libgmp10 2:6.3.0+dfsg-2
ii libisl23 0.26-3
ii libmpc31.3.1-1
ii libmpfr6 4.2.1-1
ii libstdc++6 13.2.0-7
ii libzstd1 1.5.5+dfsg2-2
ii zlib1g 1:1.2.13.dfsg-3
Versions of packages gcc-13 recommends:
ii libc6-dev 2.37-12+b1
Versions of packages gcc-13 suggests:
ii gcc-13-doc 13.2.0-1
pn gcc-13-locales
ii gcc-13-multilib 13.2.0-7
-- no debconf information
--
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/patches/hurd-amd64.diff b/debian/patches/hurd-amd64.diff
new file mode 100644
index 000..e7288ea
--- /dev/null
+++ b/debian/patches/hurd-amd64.diff
@@ -0,0 +1,127 @@
+commit 5707e9db9c398d311defc80c5b7822c9a07ead60
+Author: Samuel Thibault
+Date: Sat May 6 13:50:36 2023 +0200
+
+hurd: Add multilib paths for gnu-x86_64
+
+We need the multilib paths in gcc to find e.g. glibc crt files on
+Debian. This is essentially based on t-linux64 version.
+
+gcc/ChangeLog:
+
+* config/i386/t-gnu64: New file.
+* config.gcc [x86_64-*-gnu*]: Add i386/t-gnu64 to
+tmake_file.
+
+commit c768917402d4cba69a92c737e56e177f5b8ab0df
+Author: Samuel Thibault
+Date: Sat May 6 13:55:44 2023 +0200
+
+hurd: Ad default-pie and static-pie support
+
+This fixes the Hurd spec in the default-pie case, and adds static-pie
+support.
+
+gcc/ChangeLog:
+
+* config/i386/gnu.h: Use PIE_SPEC, add static-pie case.
+* config/i386/gnu64.h: Use PIE_SPEC, add static-pie case.
+
+diff --git a/src/gcc/config.gcc b/src/gcc/config.gcc
+index 3000379cafc..e62849c1230 100644
+--- a/src/gcc/config.gcc
b/src/gcc/config.gcc
+@@ -5973,6 +5973,9 @@ case ${target} in
+ visium-*-*)
+ target_cpu_default2="TARGET_CPU_$with_cpu"
+ ;;
++ x86_64-*-gnu*)
++ tmake_file="$tmake_file i386/t-gnu64"
++ ;;
+ esac
+
+ t=
+diff --git a/src/gcc/config/i386/t-gnu64 b/src/gcc/config/i386/t-gnu64
+new file mode 100644
+index 000..23ee6823d65
+--- /dev/null
b/src/gcc/config/i386/t-gnu64
+@@ -0,0 +1,38 @@
++# Copyright (C) 2002-2023 Free Software Foundation, Inc.
++#
++# This file is part of GCC.
++#
++# GCC is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 3, or (at your option)
++# any later version.
++#
++# GCC is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++# GNU General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with GCC; see the file COPYING3. If not see
++# <http://www.gnu.org/licenses/>.
++
++# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
++# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
++# /lib and /usr/lib, while other distributions install libraries into /lib64
++# and /usr/lib64. The LSB does not enforce the use of /lib64 and /usr/lib64,
++# it d
Bug#1040071: libelf-dev: Missing dep from libelf-dev to libzstd-dev
Package: libelf-dev
Version: 0.189-2
Severity: serious
Tags: patch
Justification: Makes glib2.0 FTBFS
Hello,
Since version 0.189, libelf.pc has libzstd in its Requires.private.
The libelf-dev package should thus depend on the libzstd-dev package,
otherwise we get:
$ pkg-config --cflags libelf
Package libzstd was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzstd.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libzstd', required by 'libelf', not found
thus breaking various packages that use libelf, e.g. glib2.0.
Samuel
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500,
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500,
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libelf-dev depends on:
ii libelf1 0.188-2.1
ii zlib1g-dev 1:1.2.13.dfsg-1
libelf-dev recommends no packages.
libelf-dev suggests no packages.
-- no debconf information
--
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-07-02 02:27:55.928634126 +0200
+++ debian/control 2023-07-02 02:28:07.188696284 +0200
@@ -53,7 +53,7 @@
Section: libdevel
Architecture: any
Multi-Arch: same
-Depends: libelf1 (= ${binary:Version}), ${misc:Depends}, zlib1g-dev
+Depends: libelf1 (= ${binary:Version}), ${misc:Depends}, zlib1g-dev,
libzstd-dev
Conflicts: libelfg0-dev
Description: libelf1 development libraries and header files
libelf1 provides a shared library which allows reading and writing of ELF
Bug#1035614: gcc-13: hurd-amd64 support
Package: gcc-13 Version: 13.1.0-1 Severity: important Tags: patch Hello, We're starting the hurd-amd64 port :) Here is a patch to add support to the gcc package (here against the master branch). Samuel -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.2.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-13 depends on: ii binutils 2.40-2 ii cpp-13 13.1.0-1 ii gcc-13-base13.1.0-1 ii libc6 2.36-9 ii libcc1-0 13.1.0-1 ii libgcc-13-dev 13.1.0-1 ii libgcc-s1 13.1.0-1 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libisl23 0.25-1 ii libmpc31.3.1-1 ii libmpfr6 4.2.0-1 ii libstdc++6 13.1.0-1 ii libzstd1 1.5.4+dfsg2-5 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gcc-13 recommends: ii libc6-dev 2.36-9 Versions of packages gcc-13 suggests: pn gcc-13-doc pn gcc-13-locales pn gcc-13-multilib -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. diff --git a/debian/control b/debian/control index 0555ad8..f131d68 100644 --- a/debian/control +++ b/debian/control @@ -5,7 +5,7 @@ Maintainer: Debian GCC Maintainers Uploaders: Matthias Klose Standards-Version: 4.6.2 Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib [amd64 i386 kfreebsd-amd64 mips mips64 mips64el mips64r6 mips64r6el mipsel mipsn32 mipsn32el mipsn32r6 mipsn32r6el mipsr6 mipsr6el powerpc ppc64 s390 s390x sparc sparc64 x32] , - libc6.1-dev (>= 2.23-1~) [alpha ia64] | libc0.3-dev (>= 2.23-1~) [hurd-i386] | libc0.1-dev (>= 2.25) [kfreebsd-i386 kfreebsd-amd64] | libc6-dev (>= 2.23-1~), libc6-dev-amd64 [i386 x32], libc6-dev-sparc64 [sparc], libc6-dev-sparc [sparc64], libc6-dev-s390 [s390x], libc6-dev-s390x [s390], libc6-dev-i386 [amd64 x32], libc6-dev-powerpc [ppc64], libc6-dev-ppc64 [powerpc], libc0.1-dev-i386 [kfreebsd-amd64], lib32gcc-s1 [amd64 ppc64 kfreebsd-amd64 mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 mips64r6el s390x sparc64 x32], libn32gcc-s1 [mips mipsel mips64 mips64el mipsr6 mipsr6el mips64r6 mips64r6el], lib64gcc-s1 [i386 mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el powerpc sparc s390 x32], libc6-dev-mips64 [mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el], libc6-dev-mipsn32 [mips mipsel mips64 mips64el mipsr6 mipsr6el mips64r6 mips64r6el], libc6-dev-mips32 [mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 mips64r6el], libc6-dev-x32 [amd64 i386], libx32gcc-s1 [amd64 i386], libc6.1-dbg [alpha ia64] | libc0.3-dbg [hurd-i386] | libc0.1-dbg [kfreebsd-i386 kfreebsd-amd64] | libc6-dbg, + libc6.1-dev (>= 2.23-1~) [alpha ia64] | libc0.3-dev (>= 2.23-1~) [hurd-amd64 hurd-i386] | libc0.1-dev (>= 2.25) [kfreebsd-i386 kfreebsd-amd64] | libc6-dev (>= 2.23-1~), libc6-dev-amd64 [i386 x32], libc6-dev-sparc64 [sparc], libc6-dev-sparc [sparc64], libc6-dev-s390 [s390x], libc6-dev-s390x [s390], libc6-dev-i386 [amd64 x32], libc6-dev-powerpc [ppc64], libc6-dev-ppc64 [powerpc], libc0.1-dev-i386 [kfreebsd-amd64], lib32gcc-s1 [amd64 ppc64 kfreebsd-amd64 mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 mips64r6el s390x sparc64 x32], libn32gcc-s1 [mips mipsel mips64 mips64el mipsr6 mipsr6el mips64r6 mips64r6el], lib64gcc-s1 [i386 mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el powerpc sparc s390 x32], libc6-dev-mips64 [mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el], libc6-dev-mipsn32 [mips mipsel mips64 mips64el mipsr6 mipsr6el mips64r6 mips64r6el], libc6-dev-mips32 [mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 mips64r6el], libc6-dev-x32 [amd64 i386], libx32gcc-s1 [amd64 i386], libc6.1-dbg [alpha ia64] | libc0.3-dbg [hurd-amd64 hurd-i386] | libc0.1-dbg [kfreebsd-i386 kfreebsd-amd64] | libc6-dbg, kfreebsd-kernel-headers (>= 0.84) [kfreebsd-any], linux-libc-dev [m68k], m4, libtool, autoconf2.69, dwz, libunwind8-dev [ia64], libatomic-ops-dev [ia64], diff --git a/debian/rules.conf b/debian/rules.conf index 78fb501..bdde0eb 100644 --- a/debian/rules.conf +++ b/debian/rules.conf @@ -110,7
Re: Bug#970614: gcc-10: Please disable systemtap-sdt-dev build-dep on non-Linux
Svante Signell, le sam. 19 sept. 2020 22:51:10 +0200, a ecrit: > On Sat, 2020-09-19 at 22:05 +0200, Samuel Thibault wrote: > > systemtap is a Linux thing, and doesn't currently build on non-Linux > > ports, could you disable the dependency as the attached patch does? > > Have you seen #969968? Ah, no, since systemtap is a Linux thing I didn't bother looking at it. Is it really useful to try to maintain systemtap building on non-Linux arch, since AIUI it's Linux-only? > Maybe you can NMU that package, or build it for -ports until upstream > or the Debian maintainer has reacted. I have uploaded to hurd's ports only, since the patches look non-trivial. Samuel
Bug#970614: gcc-10: Please disable systemtap-sdt-dev build-dep on non-Linux
Package: gcc-10 Version: 10.2.0-7 Severity: important Tags: patch Hello, systemtap is a Linux thing, and doesn't currently build on non-Linux ports, could you disable the dependency as the attached patch does? Thanks, Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-10 depends on: ii binutils 2.35-3 ii cpp-10 10.2.0-7 ii gcc-10-base10.2.0-7 ii libc6 2.31-3 ii libcc1-0 10.2.0-7 ii libgcc-10-dev 10.2.0-7 ii libgcc-s1 10.2.0-7 ii libgmp10 2:6.2.0+dfsg-6 ii libisl22 0.22.1-1 ii libmpc31.2.0-1 ii libmpfr6 4.1.0-3 ii libstdc++6 10.2.0-7 ii libzstd1 1.4.5+dfsg-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gcc-10 recommends: ii libc6-dev 2.31-3 Versions of packages gcc-10 suggests: ii gcc-10-doc 10.1.0-1 pn gcc-10-locales ii gcc-10-multilib 10.2.0-7 -- no debconf information -- Samuel Moralité : le modem et le cablerouteur font comme les filles, ils papotent toute la journée. -+- RB in NPC : Et en plus, ils ne parlent que de bits -+- commit 266bfee4ef2609ef3fb7e511748c37783271df50 Author: Samuel Thibault Date: Sat Sep 19 13:24:54 2020 +0200 Limit systemtap-sdt-dev build dependency to linux architectures diff --git a/debian/changelog b/debian/changelog index e22f761..af94789 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +gcc-10 (10.2.0-10) UNRELEASED; urgency=high + + * Limit systemtap-sdt-dev build dependency to linux architectures. + + -- Samuel Thibault Sat, 19 Sep 2020 13:24:24 +0200 + gcc-10 (10.2.0-9) unstable; urgency=high * Update to git 20200918 from the gcc-10 branch. diff --git a/debian/control b/debian/control index 2f83de6..34fc359 100644 --- a/debian/control +++ b/debian/control @@ -10,7 +10,7 @@ Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib [a m4, libtool, autoconf, dwz, libunwind8-dev [ia64], libatomic-ops-dev [ia64], gawk, lzma, xz-utils, patchutils, - libzstd-dev, zlib1g-dev, systemtap-sdt-dev [linux-any kfreebsd-any hurd-any], + libzstd-dev, zlib1g-dev, systemtap-sdt-dev [linux-any], binutils:native (>= 2.35), binutils-hppa64-linux-gnu:native (>= 2.35) [hppa amd64 i386 x32], gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, gdb:native [!riscv64], nvptx-tools [amd64 ppc64el], llvm-10 [amd64], lld-10 [amd64], diff --git a/debian/rules.conf b/debian/rules.conf index 8667ea0..75c8cca 100644 --- a/debian/rules.conf +++ b/debian/rules.conf @@ -443,7 +443,7 @@ endif AUTO_BUILD_DEP += autoconf$(autoconf_version), ifeq (,$(filter $(distrelease),lenny etch squeeze wheezy dapper hardy jaunty karmic lucid maverick natty oneiric precise quantal raring saucy trusty)) - SDT_BUILD_DEP = systemtap-sdt-dev [linux-any kfreebsd-any hurd-any], + SDT_BUILD_DEP = systemtap-sdt-dev [linux-any], endif # ensure that the common libs, built from the next GCC version are available
Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.
Matthias Klose, le lun. 18 mai 2020 16:43:06 +0200, a ecrit: > the kfreebsd bits are configured explicitly as well. You mean CONFARGS += --with-arch-32=i686 is not only for the 32bit-target-built-in-64bit-host? Then ok, and sorry for the noise. Samuel
Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.
I see that you have added --with-arch=i686 explicitly in rules2, but the thing is: it is *already* what gets enabled by default without specifying anything, just like it happens on linux-i386 and kfreebsd-i386. Keeping that special case will yet once more leave a corner case that'll bite us sooner or later. We don't want to make the hurd-i386 toolchain use special cases compared to linux and kfreebsd, just let it use the same way as linux-i386 and kfreebsd-i386. Samuel
Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.
Matthias Klose, le lun. 18 mai 2020 15:49:40 +0200, a ecrit: > On 5/18/20 3:28 PM, Samuel Thibault wrote: > > Matthias Klose, le lun. 18 mai 2020 15:25:41 +0200, a ecrit: > >> On 5/18/20 2:59 PM, Samuel Thibault wrote: > >>> It seems hurd-i386 was left with building with --with-arch=i586, while > >>> there is no reason any more to do so. I checked building glibc, hurd, > >>> gnumach, without any issue. > >> > >> is it really correct to omit this configure option, instead of setting it > >> to > >> i686 explicitly? > > > > i686 is already inherited from dpkg-architecture's output: > > > > DEB_TARGET_GNU_CPU=i686 > > DEB_TARGET_GNU_SYSTEM=gnu > > DEB_TARGET_GNU_TYPE=i686-gnu > > > > (just like on linux-any and kfreebsd-any). > > the TARGET macros are overridden because dpkg should not define the baseline. > The target macros are also bogus in case a package builds for multiple > targets. > > I'll set that directly. I'm a bit lost as to why you seem to think something needs to be set explicitly. AIUI, for linux-i386 and kfreebsd-i386 nothing explicitly says to use i686. I'm just saying that there is nothing to say for hurd-any either (and certainly not request i586 which is an old remnant from previous toolchains). And I did try to use that compiler, it does produce i686 code, so it does have the desired effect of just behaving like linux-any and kfreebsd-any, instead of having a special case for hurd-any. Samuel
Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.
Matthias Klose, le lun. 18 mai 2020 15:25:41 +0200, a ecrit: > On 5/18/20 2:59 PM, Samuel Thibault wrote: > > It seems hurd-i386 was left with building with --with-arch=i586, while > > there is no reason any more to do so. I checked building glibc, hurd, > > gnumach, without any issue. > > is it really correct to omit this configure option, instead of setting it to > i686 explicitly? i686 is already inherited from dpkg-architecture's output: DEB_TARGET_GNU_CPU=i686 DEB_TARGET_GNU_SYSTEM=gnu DEB_TARGET_GNU_TYPE=i686-gnu (just like on linux-any and kfreebsd-any). Samuel
Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.
Package: gcc-9 Version: 9.3.0-12 Severity: important Tags: patch Hello, It seems hurd-i386 was left with building with --with-arch=i586, while there is no reason any more to do so. I checked building glibc, hurd, gnumach, without any issue. This needs to be applied on gcc-10 and snapshot as well, the same patch will work, I'll clone+reassign the bug. Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-9 depends on: ii binutils 2.34-5 ii cpp-9 9.3.0-12 ii gcc-9-base9.3.0-12 ii libc6 2.30-8 ii libcc1-0 10.1.0-1 ii libgcc-9-dev 9.3.0-12 ii libgcc-s1 10.1.0-1 ii libgmp10 2:6.2.0+dfsg-4 ii libisl22 0.22.1-1 ii libmpc3 1.1.0-1 ii libmpfr6 4.0.2-1 ii libstdc++610.1.0-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages gcc-9 recommends: ii libc6-dev 2.30-8 Versions of packages gcc-9 suggests: ii gcc-9-doc 9.3.0-1 pn gcc-9-locales ii gcc-9-multilib 9.3.0-12 -- no debconf information commit 2206ac18f2c0bc3515009f56d0a7cdc01b644a15 Author: Samuel Thibault Date: Mon May 18 14:51:04 2020 +0200 debian/rules: Do not pass --with-arch=i586 on hurd-i386. diff --git a/debian/rules2 b/debian/rules2 index bdb4657..c1ec236 100644 --- a/debian/rules2 +++ b/debian/rules2 @@ -595,10 +595,6 @@ ifeq ($(multilib),yes) CONFARGS += --enable-multilib endif -ifneq (,$(filter $(DEB_TARGET_ARCH), hurd-i386)) - CONFARGS += --with-arch=i586 -endif - ifeq ($(DEB_TARGET_ARCH),lpia) CONFARGS += --with-arch=pentium-m --with-tune=i586 endif
Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd
Hello, On 20.11.19 11:43, Fabian Kloetzl wrote: > Recently, the build of one of my packages failed on hurd-i386 and > kfreebsd-* due to unsupported ifuncs [1]. However, I had that code guarded > by __has_attribute(ifunc) which, unfortunately, evaluates to 1 on said > platforms. A minimal testcase is attached. AIUI, that is expected by gcc people: the gcc documentation says: “to test whether the attribute referenced by its operand is recognized by GCC” Strictly speaking, being recognized by GCC doesn't mean being supported on the target platform. I agree that it makes it not really useful here, but I'm not the one to be convinced :) I'd say bring the issue to upstream gcc. Samuel
Re: GCC | Disable gm2 on hurd-i386, mc hangs there (!3)
Gaius Mulley, le mar. 17 sept. 2019 20:28:18 +0100, a ecrit: > I'll download a i386 hurd iso image and see if I can reproduce the 'mc' > hang, I'd say better go with a preinstalled VM image. Samuel
Re: GCC | Disable gm2 on hurd-i386, mc hangs there (!3)
Matthias Klose, le mar. 17 sept. 2019 18:40:04 +0200, a ecrit: > use the bug tracker to submit debian related patches. I'm not going to > review merge requests, but unfortunately I can't disable them. In "Settings" -> "General" -> "Visibility, project features, permission", there is a "Merge requests" part in which you can restrain merge requests to project members. That should reduce a lot the risk for such kind of merge requests. Samuel
Bug#940600: gcc-9: Please disable gm2 on hurd-i386 too
Package: gcc-9 Version: 9.2.1-4 Severity: important Tags: patch Hello, mc hangs on hurd-i386, could you disable m2 there as the attached patch does? Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-9 depends on: ii binutils 2.32.51.20190821-2 ii cpp-9 9.2.1-4 ii gcc-9-base9.2.1-4 ii libc6 2.29-1 ii libcc1-0 9.2.1-4 ii libgcc-9-dev 9.2.1-4 ii libgcc1 1:9.2.1-4 ii libgmp10 2:6.1.2+dfsg-4 ii libisl19 0.20-2 ii libmpc3 1.1.0-1 ii libmpfr6 4.0.2-1 ii libstdc++69.2.1-4 ii zlib1g1:1.2.11.dfsg-1+b1 Versions of packages gcc-9 recommends: ii libc6-dev 2.29-1 Versions of packages gcc-9 suggests: ii gcc-9-doc 9.2.0-1 pn gcc-9-locales ii gcc-9-multilib9.2.1-4 pn libasan5-dbg pn libatomic1-dbg pn libgcc1-dbg pn libgomp1-dbg pn libitm1-dbg pn liblsan0-dbg pn libquadmath0-dbg pn libtsan0-dbg pn libubsan1-dbg -- no debconf information -- Samuel ça gaze ? prout -+- #ens-mim - ouvrez les fenêtres ! -+- commit 5aabd4e720ac112f080aaca1e22e7de7887894d8 Author: Samuel Thibault Date: Thu Sep 12 08:53:23 2019 +0200 Disable gm2 on hurd-i386, mc hangs there diff --git a/debian/changelog b/debian/changelog index 3e4df82..7700fdb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,9 +1,13 @@ gcc-9 (9.2.1-9) UNRELEASED; urgency=medium + [ Matthias Klose ] * Update to SVN 20190917 (r275806) from the gcc-9-branch. - Fix PR libstdc++/91748, PR rtl-optimization/89795, PR c++/91705, PR fortran/91557, PR fortran/91553, PR fortran/91566, PR fortran/91642. + [ Samuel Thibault ] + * Disable gm2 on hurd-i386, mc hangs there. + -- Matthias Klose Tue, 17 Sep 2019 17:10:04 +0200 gcc-9 (9.2.1-8) unstable; urgency=medium diff --git a/debian/rules.defs b/debian/rules.defs index 54bad2a..dca283d 100644 --- a/debian/rules.defs +++ b/debian/rules.defs @@ -1195,7 +1195,7 @@ ifneq ($(with_base_only),yes) with_m2 := yes endif endif -m2_no_archs = powerpc ppc64 sh4 x32 kfreebsd-amd64 kfreebsd-i386 +m2_no_archs = powerpc ppc64 sh4 x32 kfreebsd-amd64 kfreebsd-i386 hurd-i386 ifneq (,$(filter $(DEB_TARGET_ARCH),$(m2_no_archs))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH) endif
Bug#894080: gcc-8: FTBFS on hurd-i386
Control: tags -1 + pending Hello, Svante Signell, le lun. 26 mars 2018 11:55:17 +0200, a ecrit: > Attached are patches to enable gccgo to build properly on Debian > GNU/Hurd on gcc-8 (8-8-20180321-1 and earlier). Fixed and applied, thanks! Samuel
Bug#893676: hurd: internal compiler error building petsc
Drew Parsons, on mer. 21 mars 2018 19:25:21 +0800, wrote: > On Wed, 2018-03-21 at 09:19 +0100, Samuel Thibault wrote: > > Drew Parsons, on mer. 21 mars 2018 12:44:03 +0800, wrote: > > > The build of PETSc 3.8 triggers an internal compiler error on hurd: > > > > > > CC i386-gnu-complex/obj/src/vec/vec/interface/vector.o > > > ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= > > > ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1)) > > > /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c: > > > In function 'VecSetInf': > > > /<>/petsc- > > > 3.8.3+dfsg1/src/vec/vec/interface/vector.c:1860:1: internal > > > compiler error: Aborted > > >} > > > > Well, perhaps it's just because the current version of gcc-7 isn't > > built. > > gcc-7 7.2.0-19 is built. The current version of gcc-7 is 7.3.0-12 > Does it mean it's not compatible with MPFR ? The old version, possibly yes. Samuel
Bug#893676: hurd: internal compiler error building petsc
Drew Parsons, on mer. 21 mars 2018 12:44:03 +0800, wrote: > The build of PETSc 3.8 triggers an internal compiler error on hurd: > > CC i386-gnu-complex/obj/src/vec/vec/interface/vector.o > ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= > ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1)) > /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c: In function > 'VecSetInf': > /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c:1860:1: > internal compiler error: Aborted >} Well, perhaps it's just because the current version of gcc-7 isn't built. Samuel
Re: Update: Hurd port for gcc-7 go : 7.3.0-8+ for glibc 2.26+
Hello,
Svante Signell, on sam. 10 mars 2018 19:33:35 +0100, wrote:
> Attached is the updated patch, src_libgo_build.diff, to build gccgo properly
> on
> Debian GNU/Hurd on gcc-7 (7-7.3.0-{8,9,10}) again after the update of glibc to
> 2.26+
I have updated the gcc-7 package in Debian, thanks!
Samuel
Bug#885056: gcc-7: Please enable PIE on hurd-i386
Package: gcc-7 Version: 7.2.0-18 Severity: important User: debian-h...@lists.debian.org Usertag: hurd Hello, We have eventually fixed the issue we had with PIE: gdb support. So could you please enable PIE by default? That should fix the build of gpgme1.0, thus unlocking a lot of packages. Samuel -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-7 depends on: ii binutils 2.29.1-12 ii cpp-7 7.2.0-18 ii gcc-7-base7.2.0-18 ii libc6 2.25-3 ii libcc1-0 8-20171102-1 ii libgcc-7-dev 7.2.0-18 ii libgcc1 1:8-20171102-1 ii libgmp10 2:6.1.2+dfsg-1.1 ii libisl15 0.18-1 ii libmpc3 1.0.3-2 ii libmpfr4 3.1.6-1 ii libstdc++68-20171102-1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages gcc-7 recommends: ii libc6-dev 2.25-3 Versions of packages gcc-7 suggests: ii gcc-7-doc 7.2.0-1 pn gcc-7-locales ii gcc-7-multilib7.2.0-18 pn libasan4-dbg pn libatomic1-dbg pn libcilkrts5-dbg pn libgcc1-dbg pn libgomp1-dbg pn libitm1-dbg pn liblsan0-dbg pn libmpx2-dbg pn libquadmath0-dbg pn libtsan0-dbg pn libubsan0-dbg -- no debconf information -- Samuel update-menus: relocation error: update-menus: symbol _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E, version GLIBCPP_3.2 not defined in file libstdc++.so.5 with link time reference quoi que ça peut bien vouloir dire ? N a eu la meme merde c ça que ça veut dire ? wow, c'est bien crypté :) -+- #ens-mim s'entraide -+-
Re: Hurd port for gcc-7 go PATCH 1-3(15)
Hello, Svante Signell, on lun. 06 nov. 2017 16:36:39 +0100, wrote: > Another issue is that /proc/self/exe has to return an absolute path for the > built program go-7 to execute properly. This is solved by a pending patch for > glibc in Debian and will be available in the next upload of glibc-2.24. FI, this was uploaded. > Adding to this, the executable ./build/gotools/go does work displaying the > help > text, but e.g. ./build/gotools/go env exits with a SIGILL: Illegal > instruction. That seems to be still happening with the updated libc. Samuel
Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
Lumin, on sam. 13 mai 2017 05:59:24 +, wrote: > > This was documented in NEWS.Debian.gz. Having to use "--compiler-options > > -fPIC" was however not documented in NEW.Debian.gz, at least that should > > be done. > > Well, what do you think we can to to deal with this bug? I Cc-ed gcc, llvm and binutils maintainers to get their opinion on this :) The problem is the move of some parts of the toolchain to pie by default, without updating the whole toolchain. Whenever not using only gcc for building object files, the issue shows up. nvcc is only an example of this. > And what can we do from the CUDA packaging side except for a new > NEWS/README.Debian section? > > I plan to point out these in the new NEWS/README.Debian section: > (1) Try to compile the whole CUDA application with clang-3.8 > (2) Append the PIE/PIC flags to compiler arguments, reference: [1] > > [1] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html That's probably a reasonable thing to do on that side, yes. Samuel
Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
Hello, Lumin, on dim. 07 mai 2017 02:29:46 +, wrote: > I'm not sure whether this bug should be marked as serious. Since your test > cases are mixing the default cc (GCC-6) and clang-3.8 together. Well, there is no choice about this: not doing so leads to: cc-c -o test.o test.c nvcc -c test-cuda.cu -o test-cuda.o ERROR: No supported gcc/g++ host compiler found, but clang-3.8 is available. Use 'nvcc -ccbin clang-3.8' to use that instead. This was documented in NEWS.Debian.gz. Having to use "--compiler-options -fPIC" was however not documented in NEW.Debian.gz, at least that should be done. > I reproduced the failure you reported, but there is a simpler solution > to the issue as shown below. > > test$ CC=clang-3.8 make > clang-3.8-c -o test.o test.c > nvcc -ccbin clang-3.8 -c test-cuda.cu -o test-cuda.o > clang-3.8 test.o test-cuda.o -lcudart -o test Ok, but that's still something difficult to the user to work out, while it is needed for basically any use of nvcc. Currently NEWS.Debian.gz only advises to use -ccbin clang-3.8. > Maybe this is a bug about GCC's linking process on a set of GCC-6 and > clang-3.8 produced objects. > Clang-3.8 is able to link a set of mixed object files while GCC-6 > fails to do so. I guess > this bug is a GCC-6 bug and not related to CUDA? Well, AIUI it's not considered a bug to require PIE, but a toolchain goal... > On the other hand, for instance, cuda application package > "caffe-contrib" was thoroughly > and finely compiled by clang-3.8 . Sure, but application Makefiles are not ready for that, we had to tinker them to use clang-3.8, and NEWS.Debian.gz only talks about the invokation of nvcc, not the eventual linking issue. Samuel
Re: Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
Samuel Thibault, on ven. 05 mai 2017 11:59:19 +0200, wrote: > Now that gcc has defaulted to building with pie, we're getting issues > with the binaries produced by nvcc: > > cc-c -o test.o test.c > nvcc -ccbin clang-3.8 -c test-cuda.cu -o test-cuda.o > cc test.o test-cuda.o -lcudart -o test > /usr/bin/ld: test-cuda.o: relocation R_X86_64_32S against `.bss' can not be > used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output That said, it's the same issue with clang-3.8, see attached testcase: cc-c -o test.o test.c clang-3.8 -c test-clang.c -o test-clang.o cc test.o test-clang.o -o test /usr/bin/ld: test-clang.o: relocation R_X86_64_32S against undefined symbol `x' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output Samuel test2.tgz Description: application/gtar-compressed
Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
Package: nvidia-cuda-toolkit Version: 8.0.44-3 Severity: serious Justification: breaks basic use of nvcc Hello, Now that gcc has defaulted to building with pie, we're getting issues with the binaries produced by nvcc: cc-c -o test.o test.c nvcc -ccbin clang-3.8 -c test-cuda.cu -o test-cuda.o cc test.o test-cuda.o -lcudart -o test /usr/bin/ld: test-cuda.o: relocation R_X86_64_32S against `.bss' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output The attached archive shows this testcase: it just builds a test.o with nvcc, and tries to link it with gcc, and that fails with the message above. This can be fixed by passing --compiler-options -fpie to nvcc, but that's something that users will have a hard time understanding, while it will be basically always needed in Stretch. So I'd tend to think /usr/bin/nvcc should actually do exec /usr/lib/nvidia-cuda-toolkit/bin/nvcc --compiler-options -fpie "$@" to save users big headaches. Samuel -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nvidia-cuda-toolkit depends on: ii clang1:3.8-36 ii clang-3.81:3.8.1-23 ii g++-55.4.1-8 ii gcc-55.4.1-8 ii libc62.24-10 ii libgcc1 1:7-20170407-1 ii libnvvm3 8.0.44-3 ii libstdc++6 7-20170407-1 ii nvidia-cuda-dev 8.0.44-3 ii nvidia-profiler 8.0.44-3 ii ocl-icd-opencl-dev [opencl-dev] 2.2.11-1 Versions of packages nvidia-cuda-toolkit recommends: pn nvidia-cuda-doc ii nvidia-cuda-gdb 8.0.44-3 ii nvidia-visual-profiler 8.0.44-3 Versions of packages nvidia-cuda-toolkit suggests: ii libcupti-dev 8.0.44-3 pn nvidia-driver -- no debconf information -- Samuel Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for Linux... (By cbbr...@io.org, Christopher Browne) test.tgz Description: application/gtar-compressed
Re: Hurd port for gcc go PATCH 1-4(23)
Samuel Thibault, on Mon 19 Dec 2016 00:25:35 +0100, wrote: > as the attached patch does, which should really be applied or done > any other way. Or rather this patch, which makes it more like the test above. Matthias, I'm committing this to Debian's gcc-6, along the other go patches from Svante. Samuel Index: gcc/src/libgo/runtime/go-caller.c === --- gcc/src/libgo/runtime/go-caller.c (révision 235086) +++ gcc/src/libgo/runtime/go-caller.c (copie de travail) @@ -93,7 +93,7 @@ argv[0] (http://gcc.gnu.org/PR61895). It would be nice to have a better check for whether this file is the real executable. */ - if (stat (filename, ) < 0 || s.st_size < 1024) + if (filename != NULL && (stat (filename, ) < 0 || s.st_size < 1024)) filename = NULL; back_state = backtrace_create_state (filename, 1, error_callback, NULL);
Re: Hurd port for gcc go PATCH 1-4(23)
Hello, Svante Signell, on Fri 25 Nov 2016 20:57:26 +0100, wrote: > Another more annoying gnumch/hurd/glibc bug is that the > built program go (go-6 in Debian) gets killed when executed from the > shell vi path, but not when issued directly: /usr/bin/go-6 works fine. > go-6 > Segmentation fault (core dumped) I've had a quick look by adding printfs in go-main.c and further to see up to where it goes before crashing. It crashes in src/libgo/runtime/go-caller.c in function __go_get_backtrace_state, inside the stat() call in: if (__builtin_strchr (filename, '/') == NULL) filename = NULL; if (stat (filename, ) < 0 || s.st_size < 1024) filename = NULL; filename of course doesn't start with '/' (it's argv[0]), and thus NULL is passed to stat(). It happens that by luck on Linux this just returns an EFAULT error, but that's sheer luck :) This should probably be turned into e.g.: if (!filename || stat (filename, ) < 0 || s.st_size < 1024) filename = NULL; as the attached patch does, which should really be applied or done any other way. Then calling go-6 brings this: fatal error: libbacktrace could not find executable to open That's inside src/libbacktrace/fileline.c, the fileline_initialize function, which tries the above filename (and thus fails), then getexecname() (which is not implemented), then /proc/self/exe, which is not implemented, then /proc/curproc/file which is even less implemented. So here it'd be "just" a matter of implementing /proc/self/exe. Samuel Index: runtime/go-caller.c === --- runtime/go-caller.c (révision 235086) +++ runtime/go-caller.c (copie de travail) @@ -93,7 +93,7 @@ argv[0] (http://gcc.gnu.org/PR61895). It would be nice to have a better check for whether this file is the real executable. */ - if (stat (filename, ) < 0 || s.st_size < 1024) + if (!filename || stat (filename, ) < 0 || s.st_size < 1024) filename = NULL; back_state = backtrace_create_state (filename, 1, error_callback, NULL);
Re: Hurd port for gcc go PATCH 1-4(23)
Svante Signell, on Wed 07 Dec 2016 15:32:31 +0100, wrote: > On Wed, 2016-12-07 at 15:08 +0100, Samuel Thibault wrote: > > Ok, but then I'd say move the function which change to a separate file, > > so that the other functions are kept shared. > > Otherwise it'll be tedious to maintain. > > One problem is the file go/syscall/libcall_posix-1.go, derived > from go/syscall/libcall_posix.go but _removing_ four function definitions: > mount, madvise, mlockall and munlockall. That's not a problem: move them out to another file, and include that file in the non-gnu case, but do not include that file in the gnu case. Actually it's even odd to see mount among them, it's not a standard posix interface. Samuel
Re: Hurd port for gcc go PATCH 1-4(23)
Svante Signell, on Wed 07 Dec 2016 14:52:35 +0100, wrote: > Since go does not have a preprocessor allowing conditional code paths this is > how it should be done (and as I did): > http://blog.ralch.com/tutorial/golang-conditional-compilation/ Ok, but then I'd say move the function which change to a separate file, so that the other functions are kept shared. Otherwise it'll be tedious to maintain. Samuel
Re: Hurd port for gcc go PATCH 1-4(23)
Svante Signell, on Sun 27 Nov 2016 18:17:17 +0100, wrote:
> On Sun, 2016-11-27 at 18:02 +0100, Samuel Thibault wrote:
> > > But as you wish, an updated patch is attached.
> >
> > _Bool
> > Continued (uint32_t *w)
> > {
> > +#ifndef WCONTINUED
> > + *w = 0;
> > + return 0;
> > +#else
> > return WIFCONTINUED (*w) != 0;
> > +#endif
> > }
> >
> > Err, recheck the semantic of WCONTINUED again, it doesn't modify its
> > parameter, it just tests its value.
> >
> > Do as I said, just return 0.
>
> No I can't the compiler complains about an unused variable. Maybe
> adding an __attribute__((unused)) to the function header?
For instance. See how it is done in the rest of the code.
> > > This is for upstream to decide.
> >
> > I'm just afraid they'd just frown on the code submission and not take
> > the time to explain how they want it to look like if we don't raise
> > the
> > discussion ourselves.
> >
>
> Should we propose these changes upstream? Or do you mean something
> else?
I mean proposing explicitly to upstream, yes, so they don't have to
take the time to explain.
> > Then ask upstream how they think it can and should be done.
>
> Upstream would be Ian Lance Taylor, right?
I don't know.
> > > > > -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum
> > > > > libgo.log
> > > > > +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
> > > >
> > > > This seems unrelated?
> > > >
> > > No, this is not unrelated: With this patch you can
> > > make -C build/i686-gnu/libgo clean
> > > make -C build/i686-gnu/libgo
> > > to rebuild libgo. Otherwise libcalls.go is not regenerated,
> > > mksysinfo.sh is not run etc.
> >
> > That's still unrelated to the matter here: porting go to
> > GNU/Hurd. It
> > looks like a bug fix which is completely independant from GNU/Hurd.
>
> Yes it is not Hurd-related. Maybe this should be filed as a separate
> bug. To gcc upstream directly?
Yes.
> > > > We could rather just implement the comm field in ps, AIUI it's
> > > > just an alias for the command field.
> > >
> > > Your choice. When implemented this patch wouldn't bee needed.
> >
> > Then please do implement it :)
>
> Sorry, I need help for doing this. Any other Hurd developer listening?
See spec_abbrevs in utils/ps.c, I guess it's a matter of adding
{"Comm=args"} in the list.
Samuel
Re: Hurd port for gcc go PATCH 1-4(23)
Hello,
Svante Signell, on Sun 27 Nov 2016 17:33:52 +0100, wrote:
> > > Index: gcc-6-6.2.1-4.1/src/libgo/go/syscall/wait.c
> > > ===
> > > --- gcc-6-6.2.1-4.1.orig/src/libgo/go/syscall/wait.c
> > > +++ gcc-6-6.2.1-4.1/src/libgo/go/syscall/wait.c
> > > @@ -8,6 +8,9 @@
> > > OS-independent. */
> > >
> > > #include
> > > +#ifndef WCONTINUED
> > > +#define WCONTINUED 0
> > > +#endif
> > > #include
> > >
> > > #include "runtime.h"
> >
> > That looks odd at best: WCONTINUED can't be defined at this place
> > anyway, so it'll get defined to 0. Fortunately the sys/wait.h
> > definition
> > would override this. But then wait.c will define something which does
> > not make sense since WCONTINUED is not implemented. Better use #ifdef
> > WCONTINUED inside the Continued function, to always return 0 when
> > it's
> > not defined.
> >
>
> I've been implementing that version too, with no visible differences.
"no visible differences" doesn't mean there is none :)
> But as you wish, an updated patch is attached.
_Bool
Continued (uint32_t *w)
{
+#ifndef WCONTINUED
+ *w = 0;
+ return 0;
+#else
return WIFCONTINUED (*w) != 0;
+#endif
}
Err, recheck the semantic of WCONTINUED again, it doesn't modify its
parameter, it just tests its value.
Do as I said, just return 0.
> This is for upstream to decide.
I'm just afraid they'd just frown on the code submission and not take
the time to explain how they want it to look like if we don't raise the
discussion ourselves.
> > And
> > src_libgo_go_syscall_syscall_gnu_test.go: New file:
> > Define Type and Whence as 32bit in syscall.Flock_t
> >
> > Again, you'll probably have to discuss with upstream to see how they
> > prefer to make it configurable rather than forking the whole file.
> >
>
> I tried to patch the syscall_unix_test.go file, but did not succeed.
> Definitely if runtime.GOOS == "GNU" ... else ... or switch runtime.GOOS
> ... does not work. The compiler sees all code and complains, also the
> else part of the code :( Therefore I created a new file.
Then ask upstream how they think it can and should be done.
> > > @@ -4431,7 +4505,7 @@ mostlyclean-local:
> > > find . -name '*-testsum' -print | xargs rm -f
> > > find . -name '*-testlog' -print | xargs rm -f
> > >
> > > -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum libgo.log
> > > +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
> >
> > This seems unrelated?
> >
> No, this is not unrelated: With this patch you can
> make -C build/i686-gnu/libgo clean
> make -C build/i686-gnu/libgo
> to rebuild libgo. Otherwise libcalls.go is not regenerated,
> mksysinfo.sh is not run etc.
That's still unrelated to the matter here: porting go to GNU/Hurd. It
looks like a bug fix which is completely independant from GNU/Hurd.
> > Svante Signell, on Fri 25 Nov 2016 21:04:58 +0100, wrote:
> > > * src_libgo_runtime_netpoll.goc.diff: Fix restricted word bug.
> > > Rename variable errno to errno1.
> > > * src_libgo_go_os_os_test.go.diff: Allow EFBIG return code to big
> > > seeks.
> > > * src_libgo_go_syscall_syscall_gnu_test.go: New file:
> > > Define Type and Whence as 32bit in syscall.Flock_t
> > > * src_libgo_testsuite_gotest.diff: Remove comm option for ps -o.
> > > * add-gnu-to-libgo-headers.diff:
> > > Add gnu to +build entry in file headers included in the build.
> > > FIXME:
> >
> > I can't find these in the patches you sent.
>
> It is in the last mail: patch 19-23(23)
Ah, sorry, mutt had pasted the content of the attached files without
putting the file names.
> > > Index: gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> > > ===
> > > --- gcc-6-6.2.1-4.1.orig/src/libgo/testsuite/gotest
> > > +++ gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> > > @@ -618,7 +618,11 @@ xno)
> > > wait $pid
> > > status=$?
> > > if ! test -f gotest-timeout; then
> > > - sleeppid=`ps -o pid,ppid,comm | grep "
> > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'`
> > > + if test "$goos" = "gnu"; then
> > > + sleeppid=`ps -o pid,ppid | grep "
> > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'`
> > > + else
> > > + sleeppid=`ps -o pid,ppid,comm | grep "
> > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'`
> > > + fi
> > > kill $alarmpid
> > > wait $alarmpid
> > > if test "$sleeppid" != ""; then
> >
> >
> > We could rather just implement the comm field in ps, AIUI it's just
> > an
> > alias for the command field.
>
> Your choice. When implemented this patch wouldn't bee needed.
Then please do implement it :)
Samuel
Re: Hurd port for gcc go PATCH 1-4(23)
Hello,
Nice work!
Mmm, why making changes in each file in a separate patch? I don't think
it makes things easier to review, I'd say rather send a big patch, it's
altogether that it makes sense anyway.
> Index: gcc-6-6.2.1-4.1/src/libgo/Makefile.in
> ===
> --- gcc-6-6.2.1-4.1.orig/src/libgo/Makefile.in
> +++ gcc-6-6.2.1-4.1/src/libgo/Makefile.in
Makefile.in is a generated file! Send the patch against Makefile.am
instead. I hope you didn't modify Makefile.in by hand?!
Svante Signell, on Fri 25 Nov 2016 20:59:27 +0100, wrote:
> Index: gcc-6-6.2.1-4.1/src/libgo/go/syscall/wait.c
> ===
> --- gcc-6-6.2.1-4.1.orig/src/libgo/go/syscall/wait.c
> +++ gcc-6-6.2.1-4.1/src/libgo/go/syscall/wait.c
> @@ -8,6 +8,9 @@
> OS-independent. */
>
> #include
> +#ifndef WCONTINUED
> +#define WCONTINUED 0
> +#endif
> #include
>
> #include "runtime.h"
That looks odd at best: WCONTINUED can't be defined at this place
anyway, so it'll get defined to 0. Fortunately the sys/wait.h definition
would override this. But then wait.c will define something which does
not make sense since WCONTINUED is not implemented. Better use #ifdef
WCONTINUED inside the Continued function, to always return 0 when it's
not defined.
> @@ -744,6 +752,14 @@ go_net_sockoptip_file = go/net/sockoptip
> go_net_cgo_sock_file = go/net/cgo_sockold.go
> go_net_cgo_res_file = go/net/cgo_resnew.go
> else
> +if LIBGO_IS_GNU
> +go_net_cgo_file = go/net/cgo_linux.go
I'd say rather rename to cgo_glibc.go . The getaddrinfo implementation
is simply exactly the same between linux, GNU/Hurd, kFreeBSD etc., there
is nothing Linux-specific here.
There are quite a few other files which could be renamed to glibc:
os/pipe_linux.go
crypto/x509/root_linux.go
syscall/errstr_linux.go
> @@ -768,11 +785,15 @@ else
> if LIBGO_IS_SOLARIS
> go_net_sendfile_file = go/net/sendfile_solaris.go
> else
> +if LIBGO_IS_GNU
> +go_net_sendfile_file = go/net/sendfile_gnu.go
> +else
> go_net_sendfile_file = go/net/sendfile_stub.go
> endif
There is no difference with the Linux version... I'd say rather propose
to rename sendfile_linux.go into sendfile_glibc.go and just use that.
> +go_net_sock_file = go/net/sock_gnu.go
> Index: gcc-6-6.2.1-4.1/src/libgo/go/net/sock_gnu.go
> ===
> --- /dev/null
> +++ gcc-6-6.2.1-4.1/src/libgo/go/net/sock_gnu.go
> @@ -0,0 +1,14 @@
> +// Copyright 2014 The Go Authors. All rights reserved.
> +// Use of this source code is governed by a BSD-style
> +// license that can be found in the LICENSE file.
> +
> +// +build gnu
> +
> +package net
> +
> +import "syscall"
> +
> +func maxListenerBacklog() int {
> + // From /usr/include/i386-gnu/bits/socket.h
> + return syscall.SOMAXCONN
> +}
Why not just using sock_stub.go which is the same?
> @@ -2028,11 +2093,20 @@ else
> syscall_os_file = go/syscall/libcall_bsd.go
> endif
>
> +# GNU/Hurd specific library calls support.
> +if LIBGO_IS_GNU
> +syscall_libcall_file = go/syscall/libcall_posix-1.go
> +syscall_os_test_file = go/syscall/syscall_gnu_test.go
> +else
> +syscall_libcall_file = go/syscall/libcall_posix.go
> +syscall_os_test_file = go/syscall/syscall_unix_test.go
> +endif
That will be probably be very much frowned upon...
What you said is:
- Removed the mount call for GNU/Hurd, it exists but use translators.
- Removed the mlockall/munlockall calls for GNU/Hurd, not yet implemented.
- Removed the madvise call for GNU/Hurd, not yet implemented.
I'd say you'd much better see with upstream how to make these
conditional inside the file itself, using ifdef GNU for mount,
HAVE_MLOCKALL and such for mlockall, munlockall, madvise, rather than
forking it all...
And
src_libgo_go_syscall_syscall_gnu_test.go: New file:
Define Type and Whence as 32bit in syscall.Flock_t
Again, you'll probably have to discuss with upstream to see how they
prefer to make it configurable rather than forking the whole file.
> @@ -4431,7 +4505,7 @@ mostlyclean-local:
> find . -name '*-testsum' -print | xargs rm -f
> find . -name '*-testlog' -print | xargs rm -f
>
> -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum libgo.log
> +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
This seems unrelated?
> Index: gcc-6-6.2.1-4.1/src/libgo/mksysinfo.sh
> ===
> --- gcc-6-6.2.1-4.1.orig/src/libgo/mksysinfo.sh
> +++ gcc-6-6.2.1-4.1/src/libgo/mksysinfo.sh
> @@ -304,6 +304,13 @@ echo '#include ' | ${CC} -x c -
>egrep '#define E[A-Z0-9_]+ ' | \
>sed -e 's/^#define \(E[A-Z0-9_]*\) .*$/const \1 = Errno(_\1)/' >> ${OUT}
>
> +# Special treatment of EWOULDBLOCK for GNU/Hurd
> +# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
> +if egrep 'define EWOULDBLOCK EAGAIN' gen-sysinfo.go > /dev/null 2>&1; then
> + egrep
Bug#783876: Seriously, these binaries should be stripped by default
Matthias Klose, on Fri 22 Apr 2016 00:47:09 +0200, wrote: > >With separate -unstripped (or whatever) packages, they could be > >installed by admin choice in those situations. > > well, admin choice is usually not the default. So this would miss the buildds. Making the buildds install extra packages & such is not very difficult. It's a matter of changing the sbuild behavior for buildd chroots. Samuel
Bug#815967: gcc-5: Updated ada-hurd.diff
Hello, Svante Signell, on Fri 26 Feb 2016 08:00:44 +0100, wrote: > This patch also applies to gcc-6, so a separate bug report will be submitted > to > the latest version in experimental. It indeed applies well on gcc-6 too. I have commited the update to both gcc-5 and gcc-6. Thanks, Samuel
Re: gcc-5 fails to build on hurd-i386
Control: tags -1 + patch Hello, Samuel Thibault, le Tue 07 Apr 2015 00:05:01 +0200, a écrit : Matthias Klose, le Sun 29 Mar 2015 21:44:37 +0200, a écrit : this looks like the same issue as for kfreebsd. help would be appreciated. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781424 I'm currently trying to build a simple fix: copy/paste the clock_getres C interface from Linux, as can be read in the attached patch. Yes, this fixes the issue for hurd-i386, and will very probably fix it for kfreebsd-* too. Samuel Index: debian/patches/ada-hurd.diff === --- debian/patches/ada-hurd.diff(révision 7956) +++ debian/patches/ada-hurd.diff(copie de travail) @@ -2,7 +2,7 @@ === --- /dev/null +++ b/src/gcc/ada/s-osinte-gnu.ads -@@ -0,0 +1,797 @@ +@@ -0,0 +1,802 @@ +-- +-- -- +--GNU ADA RUN-TIME LIBRARY (GNARL) COMPONENTS -- @@ -226,6 +226,11 @@ + return int; + pragma Import (C, clock_gettime, clock_gettime); + ++ function clock_getres ++ (clock_id : clockid_t; ++ res : access timespec) return int; ++ pragma Import (C, clock_getres, clock_getres); ++ + function To_Duration (TS : timespec) return Duration; + pragma Inline (To_Duration); + Index: debian/patches/ada-kfreebsd.diff === --- debian/patches/ada-kfreebsd.diff(révision 7956) +++ debian/patches/ada-kfreebsd.diff(copie de travail) @@ -220,6 +220,18 @@ function clock_gettime (clock_id : clockid_t; +@@ -216,6 +215,11 @@ + return int; +pragma Import (C, clock_gettime, clock_gettime); + ++ function clock_getres ++ (clock_id : clockid_t; ++ res : access timespec) return int; ++ pragma Import (C, clock_getres, clock_getres); ++ +function To_Duration (TS : timespec) return Duration; +pragma Inline (To_Duration); + @@ -252,6 +251,16 @@ package System.OS_Interface is function getpid return pid_t; pragma Import (C, getpid, getpid);
Re: gcc-5 fails to build on hurd-i386
Matthias Klose, le Sun 29 Mar 2015 21:44:37 +0200, a écrit : this looks like the same issue as for kfreebsd. help would be appreciated. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781424 I'm currently trying to build a simple fix: copy/paste the clock_getres C interface from Linux, as can be read in the attached patch. Samuel Index: debian/patches/ada-hurd.diff === --- debian/patches/ada-hurd.diff(révision 7956) +++ debian/patches/ada-hurd.diff(copie de travail) @@ -2,7 +2,7 @@ === --- /dev/null +++ b/src/gcc/ada/s-osinte-gnu.ads -@@ -0,0 +1,797 @@ +@@ -0,0 +1,802 @@ +-- +-- -- +--GNU ADA RUN-TIME LIBRARY (GNARL) COMPONENTS -- @@ -226,6 +226,11 @@ + return int; + pragma Import (C, clock_gettime, clock_gettime); + ++ function clock_getres ++ (clock_id : clockid_t; ++ res : access timespec) return int; ++ pragma Import (C, clock_getres, clock_getres); ++ + function To_Duration (TS : timespec) return Duration; + pragma Inline (To_Duration); + Index: debian/patches/ada-kfreebsd.diff === --- debian/patches/ada-kfreebsd.diff(révision 7956) +++ debian/patches/ada-kfreebsd.diff(copie de travail) @@ -220,6 +220,18 @@ function clock_gettime (clock_id : clockid_t; +@@ -216,6 +215,11 @@ + return int; +pragma Import (C, clock_gettime, clock_gettime); + ++ function clock_getres ++ (clock_id : clockid_t; ++ res : access timespec) return int; ++ pragma Import (C, clock_getres, clock_getres); ++ +function To_Duration (TS : timespec) return Duration; +pragma Inline (To_Duration); + @@ -252,6 +251,16 @@ package System.OS_Interface is function getpid return pid_t; pragma Import (C, getpid, getpid);
Bug#778440: libgcc-5-dev: hardcorded omp_nest_lock_t size breaks non-linux use
Matthias Klose, le Tue 24 Mar 2015 16:09:27 +0100, a écrit : I guess this was done in order to be able to use the same omp.h on both i386 and amd64, but I don't think this is still needed now that omp.h is in arch-specific /usr/lib/gcc/x86_64-linux-gnu/5/include/omp.h Could you consider removing this patch? this location is not arch-specific for multilibs. Argl. So I still think this is needed. And maybe even on the multilib'ed kfreebsd targets. Indeed. So better guard the bits with preprocessor macros? Yes. The issue is that for non-Linux ports libgomp uses pthread_mutex_t or sem_t, whose sizes are mostly unknown, so ideally it'd be #ifdef m32 unsigned char _x[@OMP_NEST_LOCK_SIZE_32@] __attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_32@))); #elif defined(mx32) unsigned char _x[@OMP_NEST_LOCK_SIZE_x32@] __attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_x32@))); #elif defined(m64) unsigned char _x[@OMP_NEST_LOCK_SIZE_64@] __attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_64@))); #endif the _32, _x32 and _64 values being computed by configure for the various targets. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150325012002.gk3...@type.youpi.perso.aquilenet.fr
Bug#755295: gcc testsuite on hurd-i386
Samuel Thibault, le Mon 09 Feb 2015 19:17:14 +0100, a écrit : # of unexpected failures124 To be compared with i386: # of unexpected failures94 The difference is essentially [...] some cleanup-*.c failures Those and a lot others later in the testsuite seem to be due to libstdc++ not able to unwind over the signal trampoline on hurd-i386. Apparently gdb is not either. That'd be a very good thing to fix :) Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150215011947.gj4...@type.youpi.perso.aquilenet.fr
Bug#755295: Hurd term server (was: Hurd GCC ping)
The latest Debian hurd package has a workaround to mimic Linux' behavior of never returning more than 4095 bytes for non-blocking pipe reads, which fixes the 'expect' behavior. gcc-5 is currently building on the mahler buildd with it, it'll take a few hours to complete, but by comparing the first test passes, I can confirm that there are *WAY* fewer failures with this workaround in place. So these were really due to expect/tcl bad buffering. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150209170333.ga17...@type.bordeaux.inria.fr
Bug#755295: Hurd term server (was: Hurd GCC ping)
Samuel Thibault, le Mon 09 Feb 2015 18:03:33 +0100, a écrit : by comparing the first test passes, I can confirm that there are *WAY* fewer failures with this workaround in place. And the few dozen failures I have seen so far also happen with the i386 build. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150209170843.ga18...@type.bordeaux.inria.fr
Bug#755295: Hurd term server (was: Hurd GCC ping)
Samuel Thibault, le Mon 09 Feb 2015 18:08:43 +0100, a écrit : Samuel Thibault, le Mon 09 Feb 2015 18:03:33 +0100, a écrit : by comparing the first test passes, I can confirm that there are *WAY* fewer failures with this workaround in place. And the few dozen failures I have seen so far also happen with the i386 build. === gcc Summary for unix === # of expected passes108671 # of unexpected failures124 # of unexpected successes 17 # of expected failures 276 # of unresolved testcases 1 # of unsupported tests 1496 To be compared with i386: === gcc Summary for unix === # of expected passes115039 # of unexpected failures94 # of unexpected successes 17 # of expected failures 324 # of unsupported tests 1723 The difference is essentially a few limits-fndefn.c failures, some cleanup-*.c failures and two dozen failures with only largefile.c (which I guess is about LFS). So I'd tend to think that it's relatively good and we can reassign the issue with tcl/expect. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150209181714.ga26...@type.bordeaux.inria.fr
Bug#755295: Hurd term server (was: Hurd GCC ping)
Thomas Schwinge, le Sun 18 Jan 2015 17:34:00 +0100, a écrit :
(Can you now reproduce the issue?)
Yes.
Any comments on that already? (I don't feel like
committing such a change without understanding it.)
--- term/ptyio.c
+++ term/ptyio.c
@@ -331,7 +331,7 @@ pty_io_read (struct trivfs_protid *cred,
}
}
- if (!(termflags TTY_OPEN) !qsize (outputq))
+ if (!(termflags TTY_OPEN) packet_mode)
{
pthread_mutex_unlock (global_lock);
return EIO;
I don't see why it should be done in packet mode only. The qsize check,
on the other hand, makes sense to me, we should keep it.
Samuel
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150118193829.gj2...@type.youpi.perso.aquilenet.fr
Bug#755295: Hurd term server (was: Hurd GCC ping)
Hello,
Trying a bit on Linux with buffer sizes, this really is an issue between
tcl and expect. It happens to work on Linux only by luck because Linux
never returns more than 4095 bytes on ptys. As you described earlier,
what happens is:
- expect has a 6001 bytes buffer
- tcl will read() by 4096 bunches
on Linux, the tcl read() will always get a 4095 bytes short read, and
thus provide the bytes to expect.
on Hurd, the tcl read() will get a 4096 full read, and thus tcl will
try to fill more, and eventually get an EIO error because the writer is
away.
I've rebuilt tcl and expect with the attached patches, to lower the
buffer size and thus avoid the short reads on Linux.
With the attached test and e files, I get this:
read(6, /media/erich/home/thomas/tmp/gcc..., 1024) = 1024
read(6, oating constant\r\n/media/erich/ho..., 1024) = 1024
read(6, valid suffix \rul\ on floating c..., 1024) = 1024
write(1, /media/erich/home/thomas/tmp/gcc..., 1024) = 1024
write(1, oating constant\r\n/media/erich/ho..., 1024) = 1024
write(1, valid suffix \rul\ on floating c..., 953) = 953
write(4, \0, 1) = 1
...
read(6, p/pr33466.c:31:19: error: invali..., 1024) = 1024
read(6, /gcc/testsuite/gcc.dg/cpp/pr3346..., 1024) = 1024
read(6, ch/home/thomas/tmp/gcc/trunk/gcc..., 1024) = 1024
write(1, onstant\r\n/media/erich/home/thoma..., 1024) = 1024
write(1, ffix \lku\ on floating constant\r..., 1024) = 1024
write(1, 66.c:46:18: error: invalid suffi..., 953) = 953
write(4, \0, 1) = 1
...
read(6, constant\r\n/media/erich/home/tho..., 1024) = 1024
read(6, ix \fdd\ on floating constant\r\n/..., 1024) = 1024
read(6, 0xdd6568, 1024) = -1 EIO (Input/output error)
and the output is truncated to only the 2 first series of writes!
I guess the fix should be in tcl, to store the error, and provide it to
expect only after having returned the remaining bytes.
Samuel
diff --exclude .svn --exclude .git --exclude CVS --exclude .hg -ur
tcl8.6-8.6.2+dfsg/generic/tclIO.h ../tcl8.6-8.6.2+dfsg/generic/tclIO.h
--- tcl8.6-8.6.2+dfsg/generic/tclIO.h 2014-07-31 21:17:23.0 +0200
+++ ../tcl8.6-8.6.2+dfsg/generic/tclIO.h2015-01-18 21:39:23.758270391
+0100
@@ -64,7 +64,7 @@
* The following defines the *default* buffer size for channels.
*/
-#define CHANNELBUFFER_DEFAULT_SIZE (1024 * 4)
+#define CHANNELBUFFER_DEFAULT_SIZE (1024)
/*
* The following structure describes the information saved from a call to
diff --exclude .svn --exclude .git --exclude CVS --exclude .hg -ur
expect-5.45/exp_clib.c ../expect-5.45/exp_clib.c
--- expect-5.45/exp_clib.c 2015-01-18 21:32:59.0 +0100
+++ ../expect-5.45/exp_clib.c 2015-01-18 21:31:48.873800506 +0100
@@ -1697,7 +1697,7 @@
}
-#define EXP_MATCH_MAX 2000
+#define EXP_MATCH_MAX 1000
/* public */
char *exp_buffer = 0;
char *exp_buffer_end = 0;
diff --exclude .svn --exclude .git --exclude CVS --exclude .hg -ur
expect-5.45/exp_command.c ../expect-5.45/exp_command.c
--- expect-5.45/exp_command.c 2015-01-18 21:32:59.0 +0100
+++ ../expect-5.45/exp_command.c2015-01-18 21:31:46.597882444 +0100
@@ -172,7 +172,7 @@
Tcl_Interp *interp;
char *fmt;
va_list args;
-char buffer[2000];
+char buffer[1000];
interp = TCL_VARARGS_START(Tcl_Interp *,arg1,args);
fmt = va_arg(args,char *);
diff --exclude .svn --exclude .git --exclude CVS --exclude .hg -ur
expect-5.45/expect.c ../expect-5.45/expect.c
--- expect-5.45/expect.c2015-01-18 21:32:59.0 +0100
+++ ../expect-5.45/expect.c 2015-01-18 21:31:51.653700425 +0100
@@ -44,7 +44,7 @@
#include retoglob.c /* RE 2 GLOB translator C variant */
/* initial length of strings that we can guarantee patterns can match */
-int exp_default_match_max =2000;
+int exp_default_match_max =1000;
#define INIT_EXPECT_TIMEOUT_LIT10/* seconds */
#define INIT_EXPECT_TIMEOUT10 /* seconds */
int exp_default_parity = TRUE;
diff --exclude .svn --exclude .git --exclude CVS --exclude .hg -ur
expect-5.45/exp_log.c ../expect-5.45/exp_log.c
--- expect-5.45/exp_log.c 2015-01-18 21:32:59.0 +0100
+++ ../expect-5.45/exp_log.c2015-01-18 21:31:55.105576154 +0100
@@ -44,7 +44,7 @@
* create a reasonably large buffer for the bulk of the output routines
* that are not too large
*/
-static char bigbuf[2000];
+static char bigbuf[1000];
static void expDiagWriteCharsUni _ANSI_ARGS_((Tcl_UniChar *str,int len));
@@ -303,7 +303,7 @@
{
char *fmt;
va_list args;
- char bigbuf[2000];
+ char bigbuf[1000];
int len, rc;
fmt = TCL_VARARGS_START(char *,arg1,args);
/media/erich/home/thomas/tmp/gcc/trunk/gcc/testsuite/gcc.dg/cpp/pr33466.c:8:18:
error: invalid suffix rh on floating constant
/media/erich/home/thomas/tmp/gcc/trunk/gcc/testsuite/gcc.dg/cpp/pr33466.c:9:18:
error: invalid suffix rl on floating constant
Bug#755295: Hurd term server (was: Hurd GCC ping)
Hello,
Thomas Schwinge, le Thu 09 Oct 2014 16:50:12 +0200, a écrit :
It is, after all, a regression, due to a fix recently applied by
Richard:
commit 1cfdceba98c380ad1cebb3a6b3d1f141d852c691
Author: Richard Braun rbr...@sceen.net
Date: Mon Oct 14 20:48:25 2013 +0200
term: fix read on a closed PTY
* term/ptyio.c (pty_io_read): Return EIO if the terminal has been
closed.
..., which addresses the issue filed at the end of
http://www.gnu.org/software/hurd/hurd/translator/term.html, »screen
Logout Hang«.
Does the patch below fix the expect issue?
Samuel
diff --git a/term/ptyio.c b/term/ptyio.c
index 211e70a..6b01585 100644
--- a/term/ptyio.c
+++ b/term/ptyio.c
@@ -331,7 +331,7 @@ pty_io_read (struct trivfs_protid *cred,
}
}
- if (!(termflags TTY_OPEN))
+ if (!(termflags TTY_OPEN) !qsize (outputq))
{
pthread_mutex_unlock (global_lock);
return EIO;
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20141102153823.gh2...@type.youpi.perso.aquilenet.fr
Bug#755295: Hurd term server (was: Hurd GCC ping)
Thomas Schwinge, le Thu 09 Oct 2014 14:02:39 +0200, a écrit : #!/usr/bin/expect -f # Doesn't seem to matter. #stty -cooked stty cooked #spawn sh -c /media/erich/home/thomas/tmp/gcc/755295.build/gcc/xgcc.real -B/media/erich/home/thomas/tmp/gcc/755295.build/gcc/ /media/erich/home/thomas/tmp/gcc/755295/gcc/testsuite/gcc.dg/cpp/pr33466.c -fno-diagnostics-show-caret -fdiagnostics-color=never -std=gnu99 -S -o pr33466.s 2 /tmp/e; cat /tmp/e spawn sh -c cat /tmp/e #spawn sh -c for i in \$(seq 1 99); do echo \$i \$(seq 0 50); done /tmp/d; cat /tmp/d #spawn sh -c for i in \$(seq 1 99); do echo \$i --; done /tmp/d; cat /tmp/d #spawn printf %4095d\r\nabc 1 #spawn printf %4096d%4096d\r\nabc 1 2 interact I don't manage to make this behave differently on Linux and on GNU/Hurd. Which testcase should I be enabling above? What is supposed to be the content of /tmp/e? It really seems to me the change I propose is the right way, but I haven't yet managed to trigger a failure without it. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102171311.gs2...@type.youpi.perso.aquilenet.fr
Bug#753791: Java failures in packs on hurd-i386... [Bug#753791: simgrid: FTBFS on hurd-i386]
Control: clone -1 -2 Control: reassign -2 libc0.3 There was also another issue, which was basically making boehm-gc completely ignore pointers on the main stack. This was in libc0.3, thus cloning reassigning. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140831145740.gp19...@type.youpi.perso.aquilenet.fr
Bug#753791: Java failures in packs on hurd-i386... [Bug#753791: simgrid: FTBFS on hurd-i386]
Matthias Klose, le Sun 31 Aug 2014 18:39:21 +0200, a écrit : Am 31.08.2014 um 03:10 schrieb Samuel Thibault: guess that will just fix all our issues... I'll then commit that and push upstream. is this necessary for the libgc package too? (and all embedded libgc copies in other packages)? They would suffer from the same issue, yes. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140831164141.gz19...@type.youpi.perso.aquilenet.fr
Bug#753791: Java failures in packs on hurd-i386... [Bug#753791: simgrid: FTBFS on hurd-i386]
Hello, I've dug a bit more the java failures we've been encountering for some time. The particular case of simply running gjdoc was helpful: an object gets allocated, then other happens, then the object gets used, but its method table is completely nuts. It happens that the class field of the object was modified (?!). It happens that this is a side effect of glibc making a symbol resolution (??!!). That seems to be due to the fact that boehm-gc uses sbrk to make its allocation, while glibc also uses it for its own allocator. No wonder they step on each other. Some time ago, boehm-gc was made to use mmap on kfreebsd too, not only Linux. I've just started a gcc build with using mmap on hurd too, I guess that will just fix all our issues... I'll then commit that and push upstream. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140831011051.gf19...@type.youpi.perso.aquilenet.fr
Bug#749290: g++-4.8: broken std::thread on Hurd
Pino Toscano, le Mon 26 May 2014 08:34:47 +0200, a écrit : It looks like to me there are two solutions: a) fix the GCC detection of threads on Hurd, so it uses only pthread_key_create (or another internal symbol of Hurd's libpthread) b) fix pthread_key_create in Hurd's libpthread, changing it to __pthread_key_create and declaring pthread_key_create as strong alias, just like it is done in NPTL IMHO most probably (b) is the most realistic and easy to do. I have now commited (b) in glibc. This fixes the webkitgtk build failure we've seen recently. I have updated the fixed libpthread on http://people.debian.org/~sthibault/tmp/libpthread-2.19.so (which thus now contains both the thousands-thread fix and std::thread fix). Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820210355.ga31...@type.youpi.perso.aquilenet.fr
Bug#749290: g++-4.8: broken std::thread on Hurd
Hello, Matthias Klose, le Wed 20 Aug 2014 23:39:40 +0200, a écrit : I backported the proposed fix for PR61841 in 4.9.1-6, however this doesn't seem to fix things. I don't see how their proposed fix could fix the issue we are having on GNU/Hurd. The issue mentioned on https://gcc.gnu.org/ml/gcc/2013-09/msg00196.html and alike are that libpthread doesn't get pulled at all due to toolchain changes, and thus PR61841 emits a reference to pthread_create to pull it. The issue we are having on GNU/Hurd, as explained by Pino, is that the symbol that libstdc++ looks for, __pthread_key_create, doesn't exist in our libpthread. The comment in libgcc/gthr-posix.h explains that it is on purpose that it looks for __pthread_key_create and not pthread_key_create: they want to avoid stumbling on a intercepted symbol. So there is little hope they change their strategy. As Pino explained, one solution is to make libstdc++ look for another symbol on GNU/Hurd, another it so just make Hurd's libpthread define __pthread_key_create just like Linux' does. However, please see Thomas Schwinge's mail to bug-hurd about this issue. Err, which mail about which issue? The mail I can read is Subject: Re: Hurd GCC ping Date: Wed, 20 Aug 2014 01:24:36 +0200 which is about the gcc testsuite, which he says actually goes fine, but the output somehow gets corrupted and thus analysis goes wrong. (I'm very surprised by this, glibc's testsuite log goes without a fuss). I haven't seen any other mail from Thomas, let alone about the std::thread issue at stake here. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820221039.gr3...@type.youpi.perso.aquilenet.fr
Bug#753791: simgrid: FTBFS on hurd-i386
tony mancill, le Wed 09 Jul 2014 22:26:19 -0700, a écrit : (gdb) bt #0 0x012ab278 in gnu.classpath.tools.gjdoc.Main.start(java.lang.String[])int ( this=@80c8eb0, args=@8099f98) at ../../../../../src/libjava/classpath/tools/gnu/classpath/tools/gjdoc/Main.java:1050 This is: 0x012c3270 +864: call 0x1183980 _Jv_LookupInterfaceMethodIdx@plt 0x012c3275 +869: mov%ebp,(%esp) = 0x012c3278 +872: call *%eax (gdb) info registers eax0xe9707512 -378505966 That's indeed not a valid pointer, _Jv_LookupInterfaceMethodIdx@plt returned a completely bogus value. (gdb) disassemble Dump of assembler code for function _Jv_LookupInterfaceMethodIdx(jclass klass, jclass iface, int method_idx): 0x0203d730 +0: mov0x4(%esp),%eax klass (in $eax) is 0x361fdc0 0x0203d734 +4: mov0x6c(%eax),%edx cldt = klass-idt (in $edx) is 0x80af960 0x0203d737 +7: mov0x8(%esp),%eax iface (in $eax) is 0x3698100 0x0203d73b +11:movswl (%edx),%ecx cldt-iindex (in $ecx) is 7 0x0203d73e +14:mov0x6c(%eax),%eax iface-ioffsets (in $eax) is 0x815f280 0x0203d741 +17:movswl (%eax,%ecx,2),%eax iface-ioffsets[cldt-iindex] is 2 0x0203d745 +21:add0xc(%esp),%eax method_idx is 13, thus idx is eventually 15 0x0203d749 +25:mov0x4(%edx,%eax,4),%eax and there, cldt-itable[15] brings the bogus 0xe9707512 The content of that table is indeed: (gdb) p/x ((unsigned long*) 0x80af964)[0] $95 = 0x3615900 (gdb) p/x ((unsigned long*) 0x80af964)[1] $96 = 0x362eb80 (gdb) p/x ((unsigned long*) 0x80af964)[2] $97 = 0x241d970 (gdb) p/x ((unsigned long*) 0x80af964)[3] $98 = 0x23f9060 (gdb) p/x ((unsigned long*) 0x80af964)[4] $99 = 0x241db10 (gdb) p/x ((unsigned long*) 0x80af964)[5] $100 = 0x240ae10 (gdb) p/x ((unsigned long*) 0x80af964)[6] $101 = 0x362f1c0 (gdb) p/x ((unsigned long*) 0x80af964)[7] $102 = 0x23fad60 (gdb) p/x ((unsigned long*) 0x80af964)[8] $103 = 0x23faf30 (gdb) p/x ((unsigned long*) 0x80af964)[9] $104 = 0x23fafc0 (gdb) p/x ((unsigned long*) 0x80af964)[10] $105 = 0x0 (gdb) p/x ((unsigned long*) 0x80af964)[11] $106 = 0x3620a48 (gdb) p/x ((unsigned long*) 0x80af964)[12] $107 = 0x80af990 (gdb) p/x ((unsigned long*) 0x80af964)[13] $108 = 0x14 (gdb) p/x ((unsigned long*) 0x80af964)[14] $109 = 0xe (gdb) p/x ((unsigned long*) 0x80af964)[15] $110 = 0xe9707512 Most values are proper pointers, except 0 of course, and 0x14, 0xe, 0xe9707512. I don't know how this dispatch table gets filled, and whether 15 is a sane value for it, but at least something odd is happening there. 0x0203d74d +29:ret Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140720230510.ga6...@type.youpi.perso.aquilenet.fr
Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*
Control: severity -1 important Hello, Matthias Klose, le Fri 11 Jul 2014 15:48:56 +0200, a écrit : Shouldn't the package for kfreebsd* have the files in a different sub-directory? linux just feels wrong on kfreebsd. I expect (but don't know for sure) that the resolver is smart enough to look in a sub-directory matching the os, but as I would expect not look in the directory named by a different os. you need to pass both -I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux Err, the latest gcj now happens to have jni_md.h next to jni.h, and thus brltty builds again... Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717214542.gw6...@type.youpi.perso.aquilenet.fr
Bug#754879: FTBFS on i386
Matthias Klose, le Wed 16 Jul 2014 03:55:30 +0200, a écrit : Am 15.07.2014 16:27, schrieb Michael Biebl: Source: gcc-4.9 Version: 4.9.0-11 Severity: serious The package FTBFS on i386 and hurd-i386 but successfully built in the past. Complete build log at [1] how helpful is this report? - i386: I'd appreciate an analysis what did go wrong - hurd-i386: yes, I enabled running the tests, but this isn't supposed to break issues. please could have hurd porters have a look? It didn't break. We are just having a bug between strip and fakeroot-tcp, possibly a race in the latter. I didn't get the time to rerun it through fakeroot-hurd yet. I've now scheduled it. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716071456.ge10...@type.youpi.perso.aquilenet.fr
Bug#753604: Bug#753791: simgrid: FTBFS on hurd-i386
tony mancill, le Tue 08 Jul 2014 22:20:01 -0700, a écrit : Program received signal SIGUSR1, User defined signal 1. SIGUSR1 is benign. Please use handle USR1 nostop noprint pass To let gdb continue the program, up to where there actually is an illegal instruction. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140709075016.GE8911@type
Bug#753791: simgrid: FTBFS on hurd-i386
Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit : It FTBFS on hurd [...] cd /home/user/port/simgrid/simgrid-3.11.1/doc /usr/bin/javadoc -quiet -d /home/user/port/simgrid/simgrid-3.11.1/doc/html/javadoc/ /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simgrid/*.java /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simgrid/*/*.java Segmentation fault (core dumped) Well, we have been seeing gcj-4.9 crashes in various packages recently. I don't think it's up to simgrid maintainers to look for the bug... Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140706170625.GH4818@type
Bug#751532: Bug#750811: Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*
Matthias Klose, le Mon 23 Jun 2014 15:50:49 +0200, a écrit :
so for now packages building jni bindings should have both jdk_home/include
and jdk_home/include/linux on the include path.
Well, this looks a bit odd. Upstream is used to just
-I${JAVA_HOME}/include, and it works fine with other JDKs, should it
really also include include/linux, even if it doesn't even directly
include anything from it?
Samuel
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140623140516.gf6...@type.bordeaux.inria.fr
Bug#751532: Bug#750811: Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*
Matthias Klose, le Mon 23 Jun 2014 16:12:11 +0200, a écrit :
Am 23.06.2014 16:05, schrieb Samuel Thibault:
Matthias Klose, le Mon 23 Jun 2014 15:50:49 +0200, a écrit :
so for now packages building jni bindings should have both
jdk_home/include
and jdk_home/include/linux on the include path.
Well, this looks a bit odd. Upstream is used to just
-I${JAVA_HOME}/include, and it works fine with other JDKs,
can you prove your claim? I don't see any java upstream providing jni_md.h in
${JAVA_HOME}/include (besides the openjdk debian package).
I was using openjdk from Debian indeed, but also some cygwin java
installation, which doesn't happen to make jni.h unconditionally include
jni_md.h, thus no such issue.
I've dug a bit and found
https://web.archive.org/web/2012063332/http://java.sun.com/products/jdk/faq/jni-j2sdk-faq.html
which doesn't even talk about linux/ ... So I don't really know what
I'm supposed to tell upstream, which does support most OS, including
windows, solaris, freebsd, etc.
Samuel
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140623150646.gh6...@type.bordeaux.inria.fr
Re: Why does gcc-4.9 suddenly build-depend on gdb?
Matthias Klose, le Thu 05 Jun 2014 11:49:31 +0200, a écrit : Am 04.06.2014 18:44, schrieb Ludovic Brenta: I see this was added without any comment in revision 7370. As a consequence, gcc-4.9 and gnat-4.9 both fail to build on the hurd-i386 buildd due to the missing build-dependency. Could you please explain why gcc must build-depend on gdb? to pick up a gdb which is built with libpython3. I see old gdb binaries for hurd-i386. Should gdb build on the hurd? gdb is missing some upstream patches to be able to build against the newer mig. I thought somebody was working on it, but apparently it's not there yet. I can probably build the newer version of gdb by hand against the old mig. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140605101709.gb5...@type.bordeaux.inria.fr
Bug#748024: gcc-4.9-plugin-dev: gcc plugins can not build
Package: gcc-4.9-plugin-dev
Version: 4.9.0-2
Severity: serious
Justification: Renders package unusable
Hello,
Some headers seem to be missing to make using plugins workable at all
with gcc-4.9:
$ cat test.cpp
#include gcc-plugin.h
#include tree.h
#include gimple.h
int main(void) {
return 0;
}
$ g++-4.9 test.cpp -o test -I$(g++-4.9 -print-file-name=plugin)/include
...
/usr/lib/gcc/x86_64-linux-gnu/4.9/plugin/include/gimple.h:276:22: error:
field ‘call_used’ has incomplete type ‘pt_solution’ struct pt_solution
call_used;
struct pt_solution is nowhere to be found in the plugin headers.
Samuel
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14.0 (SMP w/8 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.9-plugin-dev depends on:
ii gcc-4.9 4.9.0-2
ii gcc-4.9-base 4.9.0-2
ii libc6 2.18-5
ii libgmp-dev2:6.0.0+dfsg-4
gcc-4.9-plugin-dev recommends no packages.
gcc-4.9-plugin-dev suggests no packages.
-- no debconf information
--
Samuel
...[Linux's] capacity to talk via any medium except smoke signals.
(By Dr. Greg Wettstein, Roger Maris Cancer Center)
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140513133210.ga4...@type.bordeaux.inria.fr
Bug#714559: gcj-4.8-jdk: jni_md.h not found
Package: gcj-4.8-jdk Version: 4.8.1-5 Severity: important Hello, See this build log for the details: https://buildd.debian.org/status/fetch.php?pkg=liblouisutdmlarch=kfreebsd-amd64ver=2.4.0-1stamp=1371429318 But basically the interesting part is: /bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DLBU_PATH=\/usr/share/liblouisutdml/lbu_files/\ -DLIBLOUIS_TABLES_PATH=\/usr/share/liblouis/tables/\ -I/usr/lib/jvm/default-java/include -I/usr/include/liblouis -I/usr/include/libxml2 -O2 -MT liblouisutdml_la-Jliblouisutdml.lo -MD -MP -MF .deps/liblouisutdml_la-Jliblouisutdml.Tpo -c -o liblouisutdml_la- libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DLBU_PATH=\/usr/share/liblouisutdml/lbu_files/\ -DLIBLOUIS_TABLES_PATH=\/usr/share/liblouis/tables/\ -I/usr/lib/jvm/default-java/include -I/usr/include/liblouis -I/usr/include/libxml2 -O2 -MT liblouisutdml_la-Jliblouisutdml.lo -MD -MP -MF .deps/liblouisutdml_la-Jliblouisutdml.Tpo -c ../java/Jliblouisutdml.c -fPIC -DPIC -o .libs/liblo In file included from ../java/Jliblouisutdml.h:2:0, from ../java/Jliblouisutdml.c:29: /usr/lib/jvm/default-java/include/jni.h:52:20: fatal error: jni_md.h: No such file or directory compilation terminated. The Debian package build-depends on default-jdk, and uses CPPFLAGS += -I/usr/lib/jvm/default-java/include to point at the default java implementation. However, on kfreebsd this directory points at /usr/lib/jvm/java-1.5.0-gcj-4.7/include, which has a jni.h which unconditionally #includes jni_md.h, assuming they are in the same directory, but jni_md.h is in a linux/ subdirectory. At this point I'm not sure what we are supposed to do: disable Java extensions on such platforms (because jni_md.h perhaps doesn't work on kfreebsd?), or is there a standard way to get jni.h working? Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel Pour un père, autant mourir que de faire plein de calculs et pas s'occuper de son fils -+- y sur #ens-mim - sombres histoires de zombies -+- -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130630195859.ga26...@type.youpi.perso.aquilenet.fr
Bug#692538: gcc-snapshot: FTBFS on hurd-i386: hurd-pthread.diff applied upstream
Package: gcc-snapshot Version: 20121106-1 Severity: important Tags: patch Hello, hurd-pthread.diff was applied upstream, so please remove it from gcc-snapshot, see attached change in rules.patch Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.0.4 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel N: beep beep Miam miam? y: ++ a: kill -MIAM -1 --- debian/rules.patch.orig 2012-11-07 11:00:06.0 +0100 +++ debian/rules.patch 2012-11-07 11:00:11.0 +0100 @@ -238,7 +238,7 @@ endif ifeq ($(DEB_TARGET_ARCH_OS),hurd) - debian_patches += hurd-pthread hurd-changes + debian_patches += hurd-changes endif debian_patches += gcc-ice-hack gcc-ice-apport
Bug#657962: gcc-defaults: Add gcc-plugin-dev?
Matthias Klose, le Mon 30 Apr 2012 12:41:49 +0200, a écrit : On 30.01.2012 16:10, Samuel Thibault wrote: Samuel Thibault, le Mon 30 Jan 2012 11:17:42 +0100, a écrit : I have a package which would like to build a gcc plugin. I should however not make it build-depend on a particular gcc-4.[567]-plugin-dev package as the default version changes over time. Could gcc-defaults also provide a gcc-plugin-dev package? Actually, thinking a bit more about it, I guess I actually have to build my plugin several times, once for each supported gcc version. So we'd need something similar to python, i.e. something like gcc-all-plugin-dev, and a way to iterate over all supported gcc versions. Is this really needed? many plugins need modifications for different GCC versions, and it should be easy to add such a loop or make magic to build for different versions. There are not (yet) that many plugins for GCC. My comments were before our discussion about a dpkg trigger to rebuild the plugins automatically. I agree that we can't really blindly hope that plugins can compile with newer versions. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120430174847.gk11...@type.famille.thibault.fr
Re: Bug#670422: libstarpu-dev: uninstallable in sid: too strict gcc dependency
Andreas Beckmann, le Wed 25 Apr 2012 15:00:20 +0200, a écrit : Having the dependency on gcc-4.6 that strict implies rebuilding starpu for each gcc upload (a binNMU with appropriate dep-wait should work). Yes, that's actually the intent of the debian dependency, because the gcc plugin system enforces strict version dependency. Discussion happened to have a way to rebuild plugins automatically on gcc package upgrade etc. through a dpkg trigger, but nothing has actually happened yet. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120425130838.gg29...@type.famille.thibault.fr
Bug#668426: Add support Ada for GNU/Hurd
Svante Signell, le Thu 12 Apr 2012 14:46:22 +0200, a écrit : On Thu, 2012-04-12 at 14:14 +0200, Samuel Thibault wrote: I will handle these, as well as commiting your latest working Ada patch, which thus does not need a bug report. Are you also submitting the relevant patches to upstream? No. Please wait for my fixes before doing so (there are a couple of details to fix). Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120412124815.gb29...@type.bordeaux.inria.fr
gcc plugins and rebuilds
Hello, One of my packages (starpu) will ship a gcc plugin (already in experimental). The problem is that the gcc plugin infrastructure checks for exact version matching (in plugin_default_version_check()), i.e. plugins are supposed to be loaded only by the exact gcc that built it. That would mean that we have to rebuild the package on each gcc upload. Some other packages shipping plugins, such as dragonegg, bypass the test if some environment variable is set by the user, but that is really not safe. I'm afraid we will just have to rebuild each time? Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120321163323.gq27...@type.bordeaux.inria.fr
Re: gcc plugins and rebuilds
Ricardo Mones, le Wed 21 Mar 2012 18:16:04 +0100, a écrit : On Wed, Mar 21, 2012 at 05:33:23PM +0100, Samuel Thibault wrote: Hello, One of my packages (starpu) will ship a gcc plugin (already in experimental). The problem is that the gcc plugin infrastructure checks for exact version matching (in plugin_default_version_check()), i.e. plugins are supposed to be loaded only by the exact gcc that built it. That would mean that we have to rebuild the package on each gcc upload. Some other packages shipping plugins, such as dragonegg, bypass the test if some environment variable is set by the user, but that is really not safe. I'm afraid we will just have to rebuild each time? Looks that's the same that happens with claws-mail and the plugins shipped in claws-mail-extra-plugins. But unless the version check includes the Debian revision you only have to rebuild when gcc upstream version changes, not every upload. Apparently the check includes hashes that are unique to the build. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120321172749.gr27...@type.bordeaux.inria.fr
Re: gcc plugins and rebuilds
Yves-Alexis Perez, le Wed 21 Mar 2012 22:47:11 +0100, a écrit : Can't the plugin be rebuilt when needed (meaning, when it's used to actually build something)? That'd make it quite more involved to use. ATM you just need to pass -fplugin=/usr/lib/.../libfoo.so to gcc. Another way would be similar to dkms co. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120321225041.gc10...@type.famille.thibault.fr
Re: gcc plugins and rebuilds
Samuel Thibault, le Wed 21 Mar 2012 23:50:41 +0100, a écrit : Another way would be similar to dkms co. That could also answer the question: how to make sure that the plugins are built for all installed versions of gcc. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120321235531.gy10...@type.famille.thibault.fr
Bug#657962: gcc-defaults: Add gcc-plugin-dev?
Source: gcc-defaults Version: 1.112 Severity: normal Hello, I have a package which would like to build a gcc plugin. I should however not make it build-depend on a particular gcc-4.[567]-plugin-dev package as the default version changes over time. Could gcc-defaults also provide a gcc-plugin-dev package? Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.4 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel Thibault samuel.thiba...@fnac.net I once witnessed a long-winded, month-long flamewar over the use of mice vs. trackballs...It was very silly. (By Matt Welsh) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120130101742.ga1...@type.famille.thibault.fr
Bug#652693: gcc-4.7: FTBFS on hurd-i386
Package: gcc-4.7 Version: 4.7-20111217-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, gcc-4.7 currently FTBFS on hurd-i386 due to two things: - hurd-changes.diff doesn't apply any more due to configuration revamping, attached is an updated version. - gcc assumes that glibc means nptl. The attached hurd-fixes.diff fixes things on hurd-i386, but in the kFreeBSD case the code may have to be disabled too, since it uses LinuxThreads instead of NPTL. I don't know how we are supposed to detect whether LinuxThreads, NPTL, or something else is being used. Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.4 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash # DP: Traditional GNU systems don't have a /usr directory. However, Debian # 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. --- config.gcc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/src/gcc/config.gcc(révision 182461) +++ b/src/gcc/config.gcc(copie de travail) @@ -583,7 +583,7 @@ *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-kopensolaris*-gnu) :;; *-*-gnu*) - native_system_header_dir=/include + # native_system_header_dir=/include ;; esac # glibc / uclibc / bionic switch. --- generic-morestack.c.orig2011-12-19 21:14:52.0 +0100 +++ generic-morestack.c 2011-12-19 21:15:35.0 +0100 @@ -507,7 +507,7 @@ sigemptyset (__morestack_initial_sp.mask); sigfillset (__morestack_fullmask); -#ifdef __GLIBC__ +#if defined(__GLIBC__) defined(__SIGRTMIN) /* In glibc, the first two real time signals are used by the NPTL threading library. By taking them out of the set of signals, we avoiding copying the signal mask in pthread_sigmask. More
Re: please update patches / investigate build failures for gcc-4.7 snapshot builds
Matthias Klose, le Mon 19 Dec 2011 00:55:12 +0100, a écrit : Please have a look at the gcc-4.7 package in experimental, update patches (hurd, kfreebsd, ARM is fixed in svn), and investigate the build failures (currently ia64, but more will appear). I am doing it for hurd already, patch pending submission. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111219002121.gd4...@type.famille.thibault.fr
Re: please update and check the multiarch patches for gcc-4.5
Hello, Matthias Klose, le Thu 18 Aug 2011 23:07:15 +0200, a écrit : A re-worked multiarch patch for gcc-4.5 is in the packaging repository, currently lacking support for the hurd and kfreebsd. Please update the support, as soon as possible, and check the implementation on mips*. Basically either MULTIARCH_DIRNAME or MULTILIB_OSDIRNAMES has to be set accordingly in gcc/config/*/t-something, maybe introducing new t-files. Sorry I got caught with other things so didn't handle it. What you have commited does work on hurd-i386. Thanks, Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011082310.gg4...@type.bordeaux.inria.fr
Re: Bug#606309: trang ends with Bus error on kfreebsd-amd64
Hello, Ondřej Surý, le Wed 08 Dec 2010 10:30:46 +0100, a écrit : Trang fails with Bus error when rebuilding rng files for opendnssec on kfreebsd-amd64: and it doesn't happen on kfreebsd-i386. I'm getting the following backtrace on asdfasdf.debian.net: 0x000803cfa2c7 in __pthread_sigsuspend () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 (gdb) bt #0 0x000803cfa2c7 in __pthread_sigsuspend () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #1 0x000803cf93b8 in __pthread_wait_for_restart_signal () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #2 0x000803cf9f8c in pthread_create@@GLIBC_2.3 () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #3 0x0008029884c2 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #4 0x0008020104cf in _Jv_ThreadStart(java::lang::Thread*, _Jv_Thread_t*, void (*)(java::lang::Thread*)) () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #5 0x0008020078ea in void java::lang::Thread::start() () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #6 0x000801fbc55a in _Jv_CreateJavaVM () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #7 0x000801fbc637 in _Jv_RunMain(_Jv_VMInitArgs*, java::lang::Class*, char const*, int, char const**, bool) () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #8 0x000800820ce1 in main () from /usr/lib/x86_64-kfreebsd-gnu/libgij.so.12 #9 0x0008049f61e9 in __libc_start_main () from /lib/x86_64-kfreebsd-gnu/libc.so.0.1 #10 0x0040060c in ?? () #11 0x7fffeb38 in ?? () #12 0x001c in ?? () #13 0x in ?? () (gdb) disassemble 0x000803cfa2c7 Dump of assembler code for function __pthread_sigsuspend: 0x000803cfa2c0 +0: mov$0x155,%eax 0x000803cfa2c5 +5: syscall = 0x000803cfa2c7 +7: retq i.e. the segfault is triggered from the kernel itself. Does anybody has any idea? I'd tend to reassign this to libgcj12 or kfreebsd-8, since there doesn't seem to be anything specific to trang in this backtrace. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110616001249.ga16...@const.famille.thibault.fr
Bug#624743: cannot reproduce
found 624743 4.6.0-8 thanks Hello, hurd-i386 is also hit by the bug. Andreas Metzler, le Fri 06 May 2011 20:16:49 +0200, a écrit : On 2011-05-05 Kees Cook k...@debian.org wrote: Hi! Thanks for this report. I can't reproduce this segfault. I tried the builds both amd64 and i386, and both build fine with 4.6.0-6 for me. Do you have any minimal reproducers that might show this more specifically? Sadly I cannot reproduce this anymore either. Some of the since upgraded build-deps must have changed. I can reproduce it with gcc-4.6 4.6.0-8, but only by using valgrind: in debian/minimaltest, prepend valgrind to the line $2 -C $top/exim4.conf -bV valgrind will then warn: ==29180== Source and destination overlap in memcpy(0x6fad4e8, 0x6fad4e0, 88) ==29180==at 0x4C25F6A: memcpy (mc_replace_strmem.c:497) ==29180==by 0x13B5D9: init_lookup_list (string3.h:59) ==29180==by 0x11FF6E: main (exim.c:3615) which is the same backtrace reported here. Disassembling init_lookup_list shows this: 0x000335cb +459: cltq 0x000335cd +461: lea0x0(,%rax,8),%rdx 0x000335d5 +469: callq 0x153a8 memcpy@plt 0x000335da +474: mov%rbx,%rcx 0x000335dd +477: add0x2b6fac(%rip),%rcx# 0x2ea590 lookup_list 0x000335e4 +484: mov0x18(%rsp),%rdx i.e. a memcpy call. l * 0x000335d5 points at 59return __builtin___memmove_chk (__dest, __src, __len, __bos0 (__dest)); which is actually a memmove call, not a memcpy call! The memmove call comes from the add_lookup_to_list() inline. By replacing it with __builtin_memmove() to avoid the _chk version, I don't get any valgrind issue any more. It looks like gcc-4.6 is here erroneously optimizing __builtin___memmove_chk into a memcpy call! Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110523215927.ga3...@const.famille.thibault.fr
Bug#624632: libgcj-bc uninstallable
Package: libgcj-bc Version: 4.6.0-4 Severity: grave Justification: renders package unusable Hello, The latest upload of gcc-defaults made libgcj-bc depend on libgcj10 (= 4.6.0-1) but that version doesn't exist, only libgcj12 exists with such version. Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38 (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 libgcj-bc depends on: ii libgcj-common 1:4.4.5-4 Java runtime library (common files ii libgcj10 4.4.5-14 Java runtime library for use with libgcj-bc recommends no packages. libgcj-bc suggests no packages. -- no debconf information -- Samuel Thibault samuel.thiba...@fnac.net y update-menus: relocation error: update-menus: symbol _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E, version GLIBCPP_3.2 not defined in file libstdc++.so.5 with link time reference y quoi que ça peut bien vouloir dire ? D N a eu la meme merde y c ça que ça veut dire ? wow, c'est bien crypté :) -+- #ens-mim s'entraide -+- -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430083417.ga14...@const.famille.thibault.fr
Re: GCC-4.5 as the default for (at least some) architectures
Kurt Roeckx, le Tue 26 Apr 2011 21:28:57 +0200, a écrit : Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? There's no real reason to defer hurd-i386, as it's basically like i386, and the key packages (glibc/hurd/gnumach) already use a fixed version and can be handled independently. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426204147.gs4...@const.famille.thibault.fr
Re: DSO linking changes for wheezy
Bernhard R. Link, le Tue 16 Nov 2010 11:01:20 +0100, a écrit : * Kurt Roeckx k...@roeckx.be [101114 14:08]: People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. The following example is a bit constructed, but shows a silent change of run-time behaviour if --as-needed is passed. I wouldn't say it's really constructed. The behavior it examplifies makes sense. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116162601.gf5...@const.bordeaux.inria.fr
Re: DSO linking changes for wheezy
Steve Langasek, le Tue 16 Nov 2010 09:14:40 -0800, a écrit : I don't argue that this makes --as-needed *correct* as a default, but I think it's clear how using --as-needed may benefit a distribution in terms of reducing churn when library dependencies change. We agree on the second part, but the change of behavior makes it unacceptable as default, thus making the second part void. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116174307.gk5...@const.bordeaux.inria.fr
Re: DSO linking changes for wheezy
Florian Weimer, le Tue 16 Nov 2010 19:49:57 +0100, a écrit : * Roland McGrath: I can't see why you think --as-needed is fundamentally wrong or unnecessary. It is fundamentally wrong because -lfoo means I demand that the initializers of libfoo.so run, whether or not I called anything in it. So it's more like static linking. 8-) ?! Initializers are called dynamically, and if you upgrade the library, the new initializers will be called (and new ones will be called as well!). I don't see what you see static here. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116191430.gf5...@const.famille.thibault.fr
Re: DSO linking changes for wheezy
Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh rle...@codelibre.net wrote: What's the actual problem --as-needed is trying to solve? The answer is mainly unwanted libraries being linked in as a result of using pkg-config (and various other -config variants), though there are other, lesser, culprits. The pkg-config .pc files for gtk, gnome and other libraries add in many libraries, most of which aren't typically needed. The solution: fix the .pc files! Using --as-needed is merely papering over the actual root problem. It fixes the symptoms, but it's not addressing the actual cause. The number of packages providing broken .pc files is not large, and the number breaking due to relying on this brokenness is likely just as small. I can't see why you think --as-needed is fundamentally wrong or unnecessary. Check out http://www.gentoo.org/proj/en/qa/asneeded.xml --as-needed has saved tons of time for upgrades like Cairo in Gentoo, where Cairo had been linked to glitz which is now useless and gone. Not a problem, if Cairo was properly exposing the dep. So when people upgraded Cairo, all the software that linked against it (and also unnecessarily linked against glitz) Why did it get linked against glitz? That's where the problem is. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116011555.gt6...@const.famille.thibault.fr
Bug#584819: gcc-4.5: FTBFS on hurd-i386
reopen 584819 thanks Oops, sorry, it looks like my patch toold is quite laxist and accepted a not so exact patch, but buildds such don't accept that. The attached patch should fix the hooks content. It also moves hurd-changes to after the snapshot barrier, now that it only contains long-term changes. Thanks, Samuel Index: debian/patches/hurd-pthread.diff === --- debian/patches/hurd-pthread.diff(révision 4569) +++ debian/patches/hurd-pthread.diff(copie de travail) @@ -58,7 +58,7 @@ # if defined(GC_FREEBSD_THREADS) --- a/src/boehm-gc/configure.ac.orig 2009-02-07 22:30:12.0 + +++ b/src/boehm-gc/configure.ac2009-02-07 22:35:31.717091000 + -@@ -172,6 +172,11 @@ +@@ -180,6 +180,11 @@ AM_CPPFLAGS=$AM_CPPFLAGS -pthread THREADLIBS=-pthread ;; @@ -67,12 +67,12 @@ + AC_DEFINE(_REENTRANT) + AC_DEFINE(THREAD_LOCAL_ALLOC) + ;; - *-*-solaris*) + *-*-solaris2.8*) AC_DEFINE(GC_SOLARIS_PTHREADS,1,[support for Solaris pthreads]) # Need to use alternate thread library, otherwise gctest hangs --- a/src/boehm-gc/configure.orig 2009-02-07 22:32:34.0 + +++ b/src/boehm-gc/configure 2009-02-07 22:35:28.06565 + -@@ -5489,6 +5489,20 @@ +@@ -14893,6 +14893,20 @@ AM_CPPFLAGS=$AM_CPPFLAGS -pthread THREADLIBS=-pthread ;; @@ -90,9 +90,9 @@ +_ACEOF + + ;; - *-*-solaris*) + *-*-solaris2.8*) - cat confdefs.h \_ACEOF + $as_echo #define GC_SOLARIS_PTHREADS 1 confdefs.h --- a/src/boehm-gc/os_dep.c.orig 2009-02-07 22:37:20.0 + +++ b/src/boehm-gc/os_dep.c2009-02-07 22:37:40.0 + @@ -312,7 +312,7 @@ Index: debian/rules.patch === --- debian/rules.patch (révision 4569) +++ debian/rules.patch (copie de travail) @@ -126,7 +126,7 @@ endif ifeq ($(DEB_TARGET_ARCH_OS),hurd) - debian_patches += hurd-changes hurd-pthread + debian_patches += hurd-pthread endif ifeq ($(DEB_TARGET_ARCH),alpha) @@ -174,6 +174,10 @@ debian_patches = endif +ifeq ($(DEB_TARGET_ARCH_OS),hurd) + debian_patches += hurd-changes +endif + ifeq ($(PKGSOURCE),gcc-snapshot) debian_patches += gcc-ice-hack-trunk gcc-ice-apport-trunk else
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 binutils2.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-base4.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 libelfg00.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 libgomp14.5-20100202-1 GCC OpenMP (GOMP) support library ii libmpc2 0.8.1-1 multiple precision complex floatin ii libmpfr1ldbl2.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.thiba...@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 + +++ b/src/boehm-gc/pthread_support.c 2009-02-07 22:27:18.279505000 + @@ -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
Bug#584454: gcc-snapshot: FTBFS on hurd-i386 due to long-term difference in Debian
Package: gcc-snapshot
Version: 20100530-1
Severity: normal
Tags: patch
Hello,
gcc-snapshot currently FTBFS on hurd-i386 because Debian GNU/Hurd
doesn't strictly follow the same rules as the main GNU/Hurd: /include
does not exist on Debian GNU/Hurd. The attached patch fixes this by
dropping almost all Hurd hooks but the renaming of /include into
/usr/include (which as documented is not to be forwarded upstream), and
moving that patch to the list of patches that are always applied, even
for gcc-snapshot.
Samuel
(I'm checking gcc 4.5 ATM, the patch will probably be also to remove
every hooks from hurd-changes except the renaming).
-- 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-snapshot depends on:
ii binutils2.20.1-9 The GNU assembler, linker and bina
ii libasound2 1.0.22-2 shared library for ALSA applicatio
ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
ii libc6-dev 2.10.2-9 Embedded GNU C Library: Developmen
ii libc6-dev-i386 2.10.2-9 GNU C Library: 32-bit development
ii libc6-i386 2.10.2-9 GNU C Library: 32-bit shared libra
ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra
ii libcloog-ppl0 0.15.9-1 the Chunky Loop Generator (runtime
ii libfontconfig1 2.8.0-2.1generic font configuration library
ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii libglib2.0-02.24.1-1 The GLib library of C routines
ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library
ii libgmpxx4ldbl 2:4.3.2+dfsg-1 Multiprecision arithmetic library
ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface
ii libice6 2:1.0.6-1X11 Inter-Client Exchange library
ii libmpfr1ldbl2.4.2-3 multiple precision floating-point
ii libpango1.0-0 1.28.0-1 Layout and rendering of internatio
ii libppl-c2 0.10.2-6 Parma Polyhedra Library (C interfa
ii libppl7 0.10.2-6 Parma Polyhedra Library (runtime l
ii libsm6 2:1.1.1-1X11 Session Management library
ii libxrandr2 2:1.3.0-3X11 RandR extension library
ii libxrender1 1:0.9.5-2X Rendering Extension client libra
ii libxtst62:1.1.0-2X11 Testing -- Resource extension
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
gcc-snapshot recommends no packages.
gcc-snapshot suggests no packages.
diff -urN debian-old/patches/hurd-changes.diff debian/patches/hurd-changes.diff
--- debian-old/patches/hurd-changes.diff2010-06-03 19:09:23.0
+0200
+++ debian/patches/hurd-changes.diff2010-06-03 19:10:25.0 +0200
@@ -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(-)
+ gnu.h |3 ++-
+ 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.0 +0200
-+++ b/src/gcc/config.gcc 2009-04-26 21:36:53.0 +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*)
Re: Switch on compiler hardening defaults
Kees Cook, le Tue 27 Oct 2009 14:11:43 -0700, a écrit : On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: I would like to propose enabling[1] the GCC hardening patches that Ubuntu uses[2]. How do they work? Do they also change the free-standing compiler or only the hosted one? There is a lot of software, which (I would say) missuse the hosted compiler to build non-userspace-code, including the Linux kernel. The stack protector is conditional on being linked with libc, so, if you build with -nostdlib (as the kernel does), it is implicitly disabled. -nostdlib is a linker option, not a compiler option. The compiler would still emit references to __stack_chk_fail. What you probably mean is -ffreestanding, but it doesn't prevent references to __stack_chk_fail either, and it even produces TLS references, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838 Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525591: libffi: can't find ffi.h on hurd-i386
Package: libffi Version: 3.0.7-1 Severity: important Hello, On hurd-i386, applications can't find ffi.h because it is put in /usr/include/i486-gnu, but on hurd-i386 is not compiled with multiarch support. I guess what happens is that the filter in debian/rules catches hurd-i386, but it shouldn't. 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.29-1-amd64 (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 -- Samuel X..., c'est un millefeuille avec une couche de crème patissière, une de sauce tomate et une de crème d'anchois... Mais c'est vrai que c'est un système ouvert: tu peux y rajouter des pépites de chocolat... -+- Ol in Guide du linuxien pervers - Remettez m'en une couche ! -+- -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525083: gcc-defaults: Please enable java on hurd-i386
Package: gcc-defaults Version: 1.80 Severity: normal Tags: patch Hello, Now that hurd-i386 has gcj-4.3, could you enable java for it as per attached patch? 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.29-1-amd64 (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 -- Samuel L pour moi le seul qui est autorisé à fasciser, c moi :-) diff -ur espeak-1.40.02/debian/rules /home/samy/brl/speech/espeak-1.40.02/debian/rules --- espeak-1.40.02/debian/rules 2009-04-04 14:17:41.0 +0200 +++ /home/samy/brl/speech/espeak-1.40.02/debian/rules 2009-04-04 17:28:06.0 +0200 @@ -65,6 +65,7 @@ cd $(CURDIR)/debian/libespeak1/usr/lib ln -s $(soname).$(version) $(soname) cd $(CURDIR)/debian/libespeak1/usr/lib ln -s $(soname).$(version) libespeak.so mv $(CURDIR)/debian/libespeak1/usr/lib/libespeak.so $(CURDIR)/debian/libespeak-dev/usr/lib + install -m 644 -o root -g root src/libespeak.a $(CURDIR)/debian/libespeak-dev/usr/lib install -m 644 -o root -g root src/speak_lib.h $(CURDIR)/debian/libespeak-dev/usr/include/espeak # Build architecture-independent files here.
Bug#525083: gcc-defaults: Please enable java on hurd-i386
Oops, I overwrote the patch with something else in between, here is the proper patch. Samuel Index: debian/control === --- debian/control (révision 3602) +++ debian/control (copie de travail) @@ -4,7 +4,7 @@ Maintainer: Debian GCC Maintainers debian-gcc@lists.debian.org Uploaders: Matthias Klose d...@debian.org, Arthur Loiret aloi...@debian.org Standards-Version: 3.8.0 -Build-Depends: m4, debhelper (= 5), dpkg-dev (= 1.13.9), gcj-4.3-base (= 4.3.3-2) [!hurd-i386 !alpha !arm !hppa !sh3 !sh4], gcc-4.2-base (= 4.2.4-1), gcc-4.3-base (= 4.3.3-2), gnat-4.3-base (= 4.3.3-2) [alpha amd64 hppa i386 ia64 lpia mips mipsel powerpc ppc64 s390 sparc kfreebsd-i386], lsb-release +Build-Depends: m4, debhelper (= 5), dpkg-dev (= 1.13.9), gcj-4.3-base (= 4.3.3-2) [!alpha !arm !hppa !sh3 !sh4], gcc-4.2-base (= 4.2.4-1), gcc-4.3-base (= 4.3.3-2), gnat-4.3-base (= 4.3.3-2) [alpha amd64 hppa i386 ia64 lpia mips mipsel powerpc ppc64 s390 sparc kfreebsd-i386], lsb-release Package: cpp Priority: optional Index: debian/rules === --- debian/rules(révision 3602) +++ debian/rules(copie de travail) @@ -206,7 +206,7 @@ no_packages += gnat endif -java_no_archs := arm hurd-i386 sh3 sh4 +java_no_archs := arm sh3 sh4 ifneq (,$(filter $(DEB_HOST_ARCH),$(java_no_archs))) no_packages += gcj gij libgcj-bc endif
Bug#524671: closed by Matthias Klose d...@debian.org (Bug#524671: fixed in gcj-4.3 4.3.3-8)
Hello, Debian Bug Tracking System, le Sun 19 Apr 2009 16:06:12 +, a écrit : #524671: gcj-4.3: Fix gcj build on hurd-i386 It has been closed by Matthias Klose d...@debian.org. Cool! [Samuel Tardieu] * Fix gcj build on hurd-i386. Closes: #524671. Errr, no, Samuel Tardieu is somebody else :) Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524671: gcj-4.3: Fix gcj build on hurd-i386
Package: gcj-4.3
Version: 4.3.3-3
Severity: important
Tags: patch
Hello,
The attached patch applies upstream fixes that make gcj buildable on
hurd-i386:
- set thread_file to posix in config.gcc (as in gcc upstream)
- fix GNU/Hurd thread bits in boehm-gc (as in boehm-gc upstream)
The same patch can be applied to gcj-4.2, if you consider uploading
another it. For gcj-4.4, the patch will be different and maybe we'll
already have it applied upstream actually, so let's not handle that one
immediately.
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.29 (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 gcj-4.3 depends on:
ii gcc-4.34.3.3-3 The GNU C compiler
ii gcj-4.3-base 4.3.3-3 The GNU Compiler Collection (gcj b
ii gij-4.34.3.3-3 The GNU Java bytecode interpreter
ii java-common0.31 Base of all Java packages
ii libc6 2.9-4 GNU C Library: Shared libraries
ii libc6-dev 2.9-4 GNU C Library: Development Librari
ii libecj-java3.4.2-1 Eclipse Java compiler (library)
ii libgcc11:4.4-20090329-1 GCC support library
ii libgcj-bc 4.3.3-2 Link time only library for use wit
ii libgcj9-0 4.3.3-3 Java runtime library for use with
ii libgcj9-dev4.3.3-3 Java development headers for use w
ii libgcj9-jar4.3.3-3 Java runtime library for use with
ii libgmp3c2 2:4.2.4+dfsg-2Multiprecision arithmetic library
ii libmpfr1ldbl 2.4.1-1 multiple precision floating-point
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime
Versions of packages gcj-4.3 recommends:
ii ecj-gcj [libecj-java-gcj] 3.4.2-1standalone version of the Eclipse
ii fastjar 2:0.97-3 Jar creation utility
ii libecj-java-gcj 3.4.2-1Eclipse Java compiler (native libr
Versions of packages gcj-4.3 suggests:
ii java-gcj-compat-dev 1.0.80-1 Java runtime environment with GCJ
pn libgcj9-dbg none (no description available)
-- no debconf information
--
Samuel
m argh, pi est plus grand que 2. Ca casse tout
-+- #ens-mim -+-
--- debian/rules.patch.orig 2009-02-08 04:11:55.559079000 +
+++ debian/rules.patch 2009-02-07 14:17:13.0 +
@@ -166,7 +166,7 @@
endif
ifeq ($(DEB_TARGET_ARCH_OS),hurd)
- debian_patches += hurd-changes
+ debian_patches += hurd-changes hurd-pthread
endif
ifeq ($(DEB_TARGET_ARCH),alpha)
--- /dev/null 2007-12-29 19:47:02.0 +
+++ debian/patches/hurd-pthread.dpatch 2009-02-08 04:14:01.019273000 +
@@ -0,0 +1,205 @@
+#! /bin/sh -e
+
+dir=
+if [ $# -eq 3 -a $2 = '-d' ]; then
+pdir=-d $3
+dir=$3/
+elif [ $# -ne 1 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+case $1 in
+-patch)
+patch $pdir -f --no-backup-if-mismatch -p0 $0
+;;
+-unpatch)
+patch $pdir -f --no-backup-if-mismatch -R -p0 $0
+;;
+*)
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+esac
+exit 0
+
+# Fix pthread support in boehm-gc
+
+--- gcc/config.gcc.orig2009-02-07 14:05:00.0 +
gcc/config.gcc 2009-02-07 14:05:10.478631000 +
+@@ -490,6 +490,9 @@
+ # GNU tools are the only tools.
+ gas=yes
+ gnu_ld=yes
++ case ${enable_threads} in
++ | yes | posix) thread_file='posix' ;;
++ esac
+ # These details are the same as for Linux.
+ # But here we need a little extra magic.
+ tmake_file=t-slibgcc-elf-ver t-linux t-gnu
+--- boehm-gc/pthread_support.c.orig2009-02-07 22:27:11.828527000 +
boehm-gc/pthread_support.c 2009-02-07 22:27:18.279505000 +
+@@ -885,7 +885,7 @@
+ GC_nprocs = pthread_num_processors_np();
+ # endif
+ # if defined(GC_OSF1_THREADS) || defined(GC_AIX_THREADS) \
+- || defined(GC_SOLARIS_PTHREADS)
++ || defined(GC_SOLARIS_PTHREADS) || defined(GC_GNU_THREADS)
+ GC_nprocs = sysconf(_SC_NPROCESSORS_ONLN);
+ if (GC_nprocs = 0) GC_nprocs = 1;
+ # endif
+--- boehm-gc/include/gc_config_macros.h.orig 2009-02-07 22:25:08.240177000
+
boehm-gc/include/gc_config_macros.h2009-02-07 22:28:40.648347000
+
+@@ -6,7 +6,8 @@
+|| defined(GC_SOLARIS_PTHREADS) \
+|| defined(GC_HPUX_THREADS) \
+|| defined(GC_AIX_THREADS) \
+- || defined(GC_LINUX_THREADS))
++
software speech synthesis in d-i?
Hello, I'm starting thinking about _software_ speech synthesis in d-i. A simple solution would be to use espeakup, which connects the espeak software speech synthesis to speakup. That would however depend on: - sound kernel modules - a libespeak udeb and the latter depends on - a libstdc++ udeb - a libportaudio udeb - a libasound udeb Does it sound reasonable to debian-boot and maintainers of the corresponding packages? (I guess that will take a few MBs on the image...) I've already started to work a bit on the sound kernel modules part, something like a sound-pcm-modules kernel wedge. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487109: gdc-4.2: Please upgrade to 4.2.4-1
Package: gdc-4.2 Version: 4.2.3-1 Severity: wishlist Hello, gcc-4.2 upgraded to 4.2.4-1, could you do the same for gdc? That would actually fix bug 482519. It would also permit to install gdc on hurd-i386: for now gcc-defaults' gdc depends on gdc-4.2 (= 4.2.4-1) there. Samuel -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- Samuel Who wants to remember that escape-x-alt-control-left shift-b puts you into super-edit-debug-compile mode? (Discussion in comp.os.linux.misc on the intuitiveness of commands, especially Emacs.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483612: Bug#483613: gcc-4.3: on hurd-i386 -fstack-protector tries to link with libssp_nonshared
found 483613 4.3.1-1 found 483612 4.2.4-2 thanks Eerf, the libssp_gnu.dpatch isn't getting applied because hurd-i386 is in ssp_no_archs, please apply attached patch to gcc-[1-3]. Samuel Index: debian/rules.defs === --- debian/rules.defs (révision 3172) +++ debian/rules.defs (copie de travail) @@ -414,7 +414,7 @@ # libssp --- with_ssp := yes -ssp_no_archs = arm armel alpha hppa ia64 m68k mips mipsel hurd-i386 +ssp_no_archs = arm armel alpha hppa ia64 m68k mips mipsel ifneq (, $(filter $(DEB_TARGET_ARCH),$(ssp_no_archs))) with_ssp := not available on $(DEB_TARGET_ARCH) endif
Bug#485395: gcc-4.3: Should use GNU locales on hurd-i386 too
Package: gcc-4.3 Version: 4.3.0-5 Severity: important Tags: patch Hello, Depending on the build machine, gcc-4.3 currently FTBFS on hurd-i386 because of the symbol list and the usage of locales. See http://buildd.debian-ports.org/fetch.php?pkg=gcc-4.3ver=4.3.1-1arch=hurd-i386stamp=1212944993file=logas=raw : the build fails just because the symbols don't have __locale_struct, and that is because we have checking for C locale to use... generic at the C++ ./configure stage. The attached patch makes the hurd-i386 arch just behave like other archs: force the C locale to be considered as gnu type (which makes sense :) ) Please apply. Thanks, Samuel -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.3 depends on: ii binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina ii cpp-4.3 4.3.0-5 The GNU C preprocessor ii gcc-4.3-base4.3.0-5 The GNU Compiler Collection (base ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-5GCC support library ii libgomp14.3.0-5 GCC OpenMP (GOMP) support library Versions of packages gcc-4.3 recommends: ii libc6-dev 2.7-10 GNU C Library: Development Librari -- no debconf information -- Samuel * B kicks DW (non mais franchement) * DW was kicked -+- #ens-mim - comment ça hopeless ? -+- Index: debian/rules.defs === --- debian/rules.defs (révision 3172) +++ debian/rules.defs (copie de travail) @@ -1200,7 +1200,7 @@ # GNU locales force_gnu_locales := yes -locale_no_systems := gnu +locale_no_systems := ifneq (, $(filter $(DEB_TARGET_GNU_SYSTEM),$(locale_no_systems))) force_gnu_locales := disabled for $(DEB_TARGET_GNU_SYSTEM) endif
Re: gcc-4.[1-3] on hurd-i386 -fstack-protector tries to link with libssp_nonshared
fixed 483612 4.2.4-2 found 483613 thanks Hello, gcc-4.2=4.2.4-2 closed the bug which was intended for gcc-4.3, so reopening that and closing the proper one. Could you please fix the gcc-4.1 changelog into closing bug #483609? Thanks, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483609: gcc-4.1: on hurd-i386 -fstack-protector tries to link with libssp_nonshared
Package: gcc-4.1 Version: 4.1.2-19 Severity: important Tags: patch Hello, When using -fstack-protector, gcc tries to link with libssp_nonshared, which is not package, thus making a bunch of packages FTBFS. The attached patch fixes that by making configure notice that (just like on GNU/Linux and GNU/kfreebsd) __stack_chk_fail is available from glibc. Cheers, Samuel -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.1 depends on: ii binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina ii cpp-4.1 4.1.2-19 The GNU C preprocessor ii gcc-4.1-base4.1.2-19 The GNU Compiler Collection (base ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-3GCC support library Versions of packages gcc-4.1 recommends: ii libc6-dev 2.7-10 GNU C Library: Development Librari pn libmudflap0-dev none (no description available) -- no debconf information -- Samuel ...[Linux's] capacity to talk via any medium except smoke signals. (By Dr. Greg Wettstein, Roger Maris Cancer Center) Index: debian/patches/libssp-gnu.dpatch === --- debian/patches/libssp-gnu.dpatch(révision 3128) +++ debian/patches/libssp-gnu.dpatch(copie de travail) @@ -36,7 +36,7 @@ # Test for stack protector support in target C library. case $target in - *-*-linux*) -+ *-*-*-gnu*) ++ *-*-gnu*|*-*-*-gnu*) AC_CACHE_CHECK(__stack_chk_fail in target GNU C library, gcc_cv_libc_provides_ssp, [gcc_cv_libc_provides_ssp=no
Bug#483612: gcc-4.2: on hurd-i386 -fstack-protector tries to link with libssp_nonshared
Package: gcc-4.2
Version: 4.2.3-5
Severity: important
Tags: patch
Hello,
When using -fstack-protector, gcc tries to link with libssp_nonshared,
which is not package, thus making a bunch of packages FTBFS. The
attached patch fixes that by making configure notice that (just like on
GNU/Linux and GNU/kfreebsd) __stack_chk_fail is available from glibc.
Cheers,
Samuel
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.25
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages gcc-4.2 depends on:
ii binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina
ii cpp-4.2 4.2.3-5 The GNU C preprocessor
ii gcc-4.2-base4.2.3-5 The GNU Compiler Collection (base
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libgcc1 1:4.3.0-3GCC support library
Versions of packages gcc-4.2 recommends:
ii libc6-dev 2.7-10 GNU C Library: Development Librari
-- no debconf information
--
Samuel
...
rv_ et Ctrl alt F2 pour aller sous console
rv_ mais c koi pour passer d'un bureau a un autre !
rv_ au fait c koi le raccourci pour passer d'un bureau a un autre 'question
stupide
cycyx ça dépend du window manager et de ta conf
Firebird ce qui fonctionne toujours c'est CTRL-ALT-BCKSP
-:- SignOff rv_: #linuxfr (Read error: EOF from client)
-:- rv_ [EMAIL PROTECTED] has joined #linuxfr
rv_ Firebird: MEURT...
Index: debian/patches/libssp-gnu.dpatch
===
--- debian/patches/libssp-gnu.dpatch(révision 3128)
+++ debian/patches/libssp-gnu.dpatch(copie de travail)
@@ -34,7 +34,7 @@
# Test for stack protector support in target C library.
case $target in
- *-*-linux*)
-+ *-*-*-gnu*)
++ *-*-gnu*|*-*-*-gnu*)
echo $as_me:$LINENO: checking __stack_chk_fail in target GNU C library
5
echo $ECHO_N checking __stack_chk_fail in target GNU C library... $ECHO_C
6
if test ${gcc_cv_libc_provides_ssp+set} = set; then
@@ -45,7 +45,7 @@
# Test for stack protector support in target C library.
case $target in
- *-*-linux*)
-+ *-*-*-gnu*)
++ *-*-gnu*|*-*-*-gnu*)
AC_CACHE_CHECK(__stack_chk_fail in target GNU C library,
gcc_cv_libc_provides_ssp,
[gcc_cv_libc_provides_ssp=no
