Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?
On Mon, Apr 15, 2024 at 06:10:16PM +0200, Helmut Grohne wrote: > In any case, I looked into prototyping this suggested move as a patch to > the gcc packaging. I am attaching a proof-of-concept of this, but I'm > not particularly fond of it as it noticeably increases the packaging > complexity. I am adding a lot of "addons" and pull a bit of code from > various debian/rules.d/binary-*.mk to a new > debian/rules.d/binary-forhost.mk such that prefixes that were only used > in a particular file are now spread to multiple. For instance, all > ?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier > and are now spread out to debian/rules.d/binary-forhost.mk. This move is > rooted in the fact that inclusion of debian/rules.d/binary-*.mk is > conditionalized. > > So initially, I am more interested in figuring out whether this is the > right direction and as a secondary question conditional to the answer of > the first, how to improve the patch to make that work. I have added this patch to rebootstrap now and it has generally improved bootstrapping. In particular, gcc-N-for-host is practically coinstallable. I am more and more convinced that this is the right direction. Do you have fundamental objections? Do you see ways to improve the patch? Helmut
Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?
Source: gcc-14 Version: 14-20240121-1 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap X-Debbugs-Cc: debian-cr...@lists.debian.org Hello Matthias, the -for-host stuff doesn't quite work for architecture cross bootstrap yet and I'm looking into why. What initially seemed like a trivial question turned out be a bit subtle. Which gcc builds should emit -for-host packages? This may sound like an obvious question initially, but looking beneath makes it a little less obvious. It is relatively obvious that native builds and cross builds (build!=host=target) should both emit -for-host packages. The question becomes more interesting when you look into cross toolchain builds. >From an end-user pov using a cross toolchain, there is no need for -for-host packages. They can use a built cross toolchain entirely without these packages as -for-host packages effectively are metapackages. If we look at e.g. src:gcc-14-cross, it builds e.g. gcc-14-aarch64-linux-gnu, so in principle it could be emitting gcc-14-for-host:arm64, but since host!=target, we can never include this binary package in a .changes files nor upload it to the archive. We can see that cross toolchain builds via src:gcc-14-cross must not include -for-host packages. Likewise, cross-toolchain-base cannot include them. The point where we really need -for-host packages is when we need to satisfy Debian package dependencies in a cross build setting. In this setting, we also need libstdc++-14-dev and others. This is not something you get from a cross toolchain build (unless you patch in the with_deps_on_target_arch_pkgs patch that you removed and is now available in cross-gcc-dev). So when you need libstdc++-14-dev, you end up building DEB_STAGE=rtlibs (or using natively built packages for your target architecture) and when you do not need libstdc++-14-dev, you almost certainly also won't need -for-host packages. Quite clearly, doing both a cross toolchain build and a DEB_STAGE=rtlibs build should result in -for-host packages and ideally should produce them only once. Currently, the cross toolchain build produces them and the DEB_STAGE=rtlibs build does not produce them. Given my reasoning in the previous paragraph, it would also be plausible to emit them from DEB_STAGE=rtlibs only. Another aspect is the content of -for-host packages. They install their doc directory as a symbolic link to $(p_xbase). In a cross toolchain build (without with_deps_on_target_arch_pkgs), p_xbase ends up being target-dependent. Hence, the symlink target in these -for-host packages differs. While native builds and cross builds link to gcc-14-base, cross toolchains link to gcc-14$(cross_bin_arch)-base and dpkg very much does not like Multi-Arch: same packages to install conflicting symbolic links. As a result, the -for-host packages we emit from cross toolchain builds cannot be installed concurrently with any other -for-host package significantly defeating their purpose. I looked into fixing this problem and the obvious thing to try is changing the symlink targets in cross toolchain builds to also point to gcc-14-base. As a consequence, they also depend on gcc-14-base, but a cross toolchain build does not currently produce a gcc-14-base package for the target architecture. If we were producing it, both the cross toolchain build and the DEB_STAGE=rtlibs build were producing them and a user would have to choose which one of them to use. It also means introducing another variant of naming base packages besides p_base, p_lbase and p_xbase which already are non-trivial to understand. If we were moving the -for-host packages from the cross toolchain build to the DEB_STAGE=rtlibs build, they would automatically reference the right base package, because the runtime libraries also link their documentation to it. On the flip side, the resulting -for-host packages would not have satisfiable dependencies unless combining with a cross toolchain build (or a native compiler for the target architecture), so the DEB_STAGE=rtlibs would no longer be self-contained in a sense. This move would not affect gcc-14-cross nor cross-toolchain-base, because neither of them include -for-host packages (as we saw earlier). In writing this, I am providing arguments that rather strongly suggest that we should move them from the cross toolchain build to the DEB_STAGE=rtlibs build, but is this really the right conclusion or am I missing something? In any case, I looked into prototyping this suggested move as a patch to the gcc packaging. I am attaching a proof-of-concept of this, but I'm not particularly fond of it as it noticeably increases the packaging complexity. I am adding a lot of "addons" and pull a bit of code from various debian/rules.d/binary-*.mk to a new debian/rules.d/binary-forhost.mk such that prefixes that were only used in a particular file are now spread to multiple. For instance, all ?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier and are now
Bug#1069066: LIMITS_H_TEST is frequently wrong on Debian
Source: gcc-14
Tags: patch upstream
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
User: helm...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian-cr...@lists.debian.org
Hi Matthias,
I've been fighting LIMITS_H_TEST for a long time. The basic problem with
it is that it uses different search paths from the actual compiler and
thus ends up occasionally detecting absence of limits.h when limits.h
really does exist. There have been various attempts to rectify this and
most of them are documented in the forwarded gcc ticket. Ultimately
though, I think the best course of action is deferring the check from a
build-time check to a run-time check thus using the actual compiler's
search path removing any possibility for misdetection. This can be done
using has_include_next in principle, but until recently,
has_include_next was broken on gcc in ways that would make this solution
inapplicable. These problems with has_include_next have recently been
resolved in gcc-14 and the Debian package includes a working version. As
a result I suggest that we also move forward with my proposed
LIMITS_H_TEST replacement in Debian. Upstream gcc fails to move forward
here and the problem affects Debian in particular due to our use of
multiarch and our changing of the compiler search path. Would you agree
to carry this as a Debian patch until gcc manages to fix it one way or
another? I've been using this last iteration of the patch for quite a
while now and didn't have any misdetections since.
Helmut
--- a/src/gcc/limitx.h
+++ b/src/gcc/limitx.h
@@ -29,7 +29,7 @@
#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */
#define _GCC_LIMITS_H_
-#ifndef _LIBC_LIMITS_H_
+#if !defined(_LIBC_LIMITS_H_) && __has_include_next()
/* Use "..." so that we find syslimits.h only in this same directory. */
#include "syslimits.h"
#endif
--- a/src/gcc/limity.h
+++ b/src/gcc/limity.h
@@ -3,7 +3,7 @@
#else /* not _GCC_LIMITS_H_ */
-#ifdef _GCC_NEXT_LIMITS_H
+#if defined(_GCC_NEXT_LIMITS_H) && __has_include_next()
#include_next /* recurse down to the real one */
#endif
--- a/src/gcc/Makefile.in
+++ b/src/gcc/Makefile.in
@@ -3139,11 +3139,7 @@
sysroot_headers_suffix=`echo $${ml} | sed -e 's/;.*$$//'`; \
multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
include_dir=include$${multi_dir}; \
- if $(LIMITS_H_TEST) ; then \
- cat $(srcdir)/limitx.h $(T_GLIMITS_H) $(srcdir)/limity.h > tmp-xlimits.h; \
- else \
- cat $(T_GLIMITS_H) > tmp-xlimits.h; \
- fi; \
+ cat $(srcdir)/limitx.h $(T_GLIMITS_H) $(srcdir)/limity.h > tmp-xlimits.h; \
$(mkinstalldirs) $${include_dir}; \
chmod a+rx $${include_dir} || true; \
$(SHELL) $(srcdir)/../move-if-change \
Bug#1067904: $frontend-$version-for-host: versioned dependency too strict
Source: gcc-14
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags rebootstrap
Hi Matthias,
thanks for merging my -for-host work. I'm looking into making practical
use of it and a major issue is the following dependency:
$FRONTEND-$VERSION-for-host:$DEB_HOST_ARCH ->
$FRONTEND-$VERSION-$DEB_HOST_GNU_TYPE (= ${gcc:Version})
While this works nicely for native compilers, trying to use the
-for-host package with a cross toolchain is doomed to fail, because it
always has different version. The equal constraint is too strict to make
practical use of these -for-host packages. I think we should change (=
${gcc:Version}) to (>= ${gcc:SoftVersion}) as is done elsewhere. Do you
agree?
I'm attaching the obvious patch.
Helmut
commit 843e8ae7602a0ec16c67d7064396fa2acd1182cd
Author: Helmut Grohne
Date: Fri Mar 22 09:35:04 2024 +0100
use gcc:SoftVersion for -for-host dependencies
diff --git a/debian/control.m4 b/debian/control.m4
index 4b6c61b8..61a4d3a8 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -804,7 +804,7 @@ Package: gcc`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gcc`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gcc`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
cpp`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU C compiler for the host architecture
@@ -929,7 +929,7 @@ Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
Section: ifdef(`TARGET',`devel',`interpreters')
-Depends: BASEDEP, cpp`'PV`'${target:suffix} (= ${gcc:Version}), ${misc:Depends}
+Depends: BASEDEP, cpp`'PV`'${target:suffix} (>= ${gcc:SoftVersion}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU C preprocessor for the host architecture
A macro processor that is used automatically by the GNU C compiler
@@ -1019,7 +1019,7 @@ Package: g++`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, g++`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, g++`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU C++ compiler for the host architecture
@@ -2522,7 +2522,7 @@ Package: gobjc++`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gobjc++`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gobjc++`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
gobjc`'PV`'-for-host (= ${gcc:Version}), g++`'PV`'-for-host (= ${gcc:Version}),
${misc:Depends}
BUILT_USING`'dnl
@@ -2599,7 +2599,7 @@ Package: gobjc`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gobjc`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gobjc`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
gobjc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU Objective-C compiler for the host architecture
@@ -2844,7 +2844,7 @@ Package: gfortran`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gfortran`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gfortran`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU Fortran compiler for the host architecture
@@ -3111,7 +3111,7 @@ Package: gccgo`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gccgo`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gccgo`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU Go compiler for the host architecture
@@ -3821,7 +3821,7 @@ Package: gnat`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gnat`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gnat`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU Ada compiler for the host architecture
@@ -3981,7 +3981,7 @@ Package: gdc`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gdc`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gdc`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
BUILT_USING`'dnl
Description: GNU D compiler (version 2) for the host architecture
@@ -4268,7 +4268,7 @@ Package: gm2`'PV`'-for-host
Architecture: ifdef(`TARGET',`TARGET',`any')
TARGET_PACKAGE`'dnl
Multi-Arch: same
-Depends: BASEDEP, gm2`'PV`'${target:suffix} (= ${gcc:
Bug#1063664: gcc-13-cross: file conflicts between gnat-13- and gnat-{9,10}-
user debian...@lists.debian.org
usertags 1063664 + fileconflict
reassign 1063664
gnat-13-aarch64-linux-gnu,gnat-13-arm-linux-gnueabihf,gnat-13-i686-linux-gnu,gnat-13-powerpc64le-linux-gnu,gnat-13-riscv64-linux-gnu,gnat-13-s390x-linux-gnu
found 1063664 10.5.0-1cross2
affects 1063664 + gnat-10-aarch64-linux-gnu gnat-10-arm-linux-gnueabihf
gnat-10-i686-linux-gnu gnat-10-powerpc64le-linux-gnu gnat-10-riscv64-linux-gnu
gnat-10-s390x-linux-gnu gnat-11-aarch64-linux-gnu gnat-11-arm-linux-gnueabihf
gnat-11-i686-linux-gnu gnat-11-powerpc64le-linux-gnu gnat-11-riscv64-linux-gnu
gnat-11-s390x-linux-gnu gnat-12-aarch64-linux-gnu gnat-12-arm-linux-gnueabihf
gnat-12-i686-linux-gnu gnat-12-powerpc64le-linux-gnu gnat-12-riscv64-linux-gnu
gnat-12-s390x-linux-gnu gnat-9-aarch64-linux-gnu gnat-9-arm-linux-gnueabihf
gnat-9-i686-linux-gnu gnat-9-powerpc64le-linux-gnu gnat-9-riscv64-linux-gnu
gnat-9-s390x-linux-gnu
tags 1063664 + patch
thanks
On Sat, Feb 10, 2024 at 07:55:09PM +0100, Andreas Beckmann wrote:
> there are undeclared file conflicts between gnat-13- and
> gnat-{9,10}- in sid. (but not between -9- and -10-).
> Maybe it would be sufficient to rebuild the package against gcc-13
> 13.2.0-13 which had some gnat conflict fixes.
I confirm. Usually, the higher gnat version declares Conflicts for the
lower one. Starting with gcc-14, the unversioned link is no longer
provided and gnat is part of gcc-defaults, so this problem will go away
in future. I also verified that src:gcc-13 already issues these
Conflicts and that a no-change upload of gcc-13-cross adds these
Conflicts to the cross toolchain packages. Hence tagging the issue as
patch.
Matthias, would you do that upload?
Helmut
Bug#1060001: libgcc-s1: move libgcc_s.so.1 to /usr for DEP17
Package: libgcc-s1 Version: 13.2.0-8 Tags: patch User: helm...@debian.org Usertags: dep17 Hi Matthias, for finalizing the /usr-merge transition via DEP17, we want to move all aliased files to /usr. I'm attaching a patch that implements this for libgcc_s.so.1 which is the only file from the gcc-13 source package affected (+ multilibs). Since this change must not affect bookworm and earlier, I've implemented it in a backports-compatible way. Helmut --- a/debian/rules2 +++ b/debian/rules2 @@ -971,17 +971,20 @@ endif # PFL is the installation prefix with DEB_TARGET_GNU_TYPE attached for cross builds -ifeq ($(DEB_CROSS),yes) - PFL = $(PF)/$(DEB_TARGET_GNU_TYPE) +PFL = $(PF) +# RPF is the base prefix or installation prefix with DEB_TARGET_GNU_TYPE attached for cross builds +# DEP17: move to /usr in trixie and noble +ifneq (,$(filter $(distrelease),jessie stretch buster bullseye bookworm precise trusty xenial bionic focal groovy hirsute impish jammy kinetic lunar mantic)) + RPF = else - PFL = $(PF) + RPF = $(PF) endif -# RPF is the base prefix or installation prefix with DEB_TARGET_GNU_TYPE attached for cross builds ifeq ($(DEB_CROSS),yes) +ifneq ($(DEB_STAGE),rtlibs) + PFL = $(PF)/$(DEB_TARGET_GNU_TYPE) RPF = $(PF)/$(DEB_TARGET_GNU_TYPE) -else - RPF = +endif endif ifeq ($(with_multiarch_lib),yes) @@ -1053,8 +1056,6 @@ endif ifeq ($(DEB_STAGE)-$(DEB_CROSS),rtlibs-yes) - PFL = $(PF) - RPF = libdir = lib/$(DEB_TARGET_MULTIARCH) usr_lib = $(PF)/lib/$(DEB_TARGET_MULTIARCH) endif
Bug#1057813: elfutils FTCBFS: leaks host flags into native build
Source: elfutils Version: 0.190-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs elfutils fails to cross build from source for amd64 and arm64 both of which recently added architecture-specific compiler flags such as PAC/BTI. These leak into the native build pass where the compiler may not understand them. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru elfutils-0.190/debian/changelog elfutils-0.190/debian/changelog --- elfutils-0.190/debian/changelog 2023-11-16 14:54:07.0 +0100 +++ elfutils-0.190/debian/changelog 2023-12-08 07:38:31.0 +0100 @@ -1,3 +1,10 @@ +elfutils (0.190-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Do not leak host flags into native build. (Closes: #-1) + + -- Helmut Grohne Fri, 08 Dec 2023 07:38:31 +0100 + elfutils (0.190-1) unstable; urgency=medium * New upstream version. diff --minimal -Nru elfutils-0.190/debian/rules elfutils-0.190/debian/rules --- elfutils-0.190/debian/rules 2023-01-14 14:54:50.0 +0100 +++ elfutils-0.190/debian/rules 2023-12-08 07:38:31.0 +0100 @@ -68,6 +68,10 @@ dh_autoreconf @mkdir -p stamps ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) + CFLAGS='$(CFLAGS_FOR_BUILD)' \ + CPPFLAGS='$(CPPFLAGS_FOR_BUILD)' \ + CXXFLAGS='$(CXXFLAGS_FOR_BUILD)' \ + LDFLAGS='$(LDFLAGS_FOR_BUILD)' \ ./configure --enable-maintainer-mode \ --enable-libdebuginfod=dummy \ --disable-debuginfod
Bug#1042482: multilib lsan packages: dysfunctional?
Control: clone -1 -2 Control: retitle -2 gcc-13: missing debhelper dependency for cross toolchain builds Control: tags -2 = Control: severity -2 normal Hi Matthias, On Sun, Jul 30, 2023 at 09:40:35PM +0200, Helmut Grohne wrote: > On Sun, Jul 30, 2023 at 07:10:09AM +0200, Matthias Klose wrote: > > see src/libsanitizer/configure.tgt, it's unsupported, the empty packages > > don't hurt. Feel free to send a patch not to build these packages, tested > > please for amd64 and i386 builds, plus cross builds targeting these > > architectures. > > Thank you for pointing there. A key insight there is that lsan does not > work for 32bit architectures at all. Therefore, we can entirely remove > the 32bit lsan multilib packages. Surprisingly, the lib64lsan0 package > is already commented, so we don't have to consider that. I've > implemented the requested change and performed a local native build on > amd64. I've also performed the requested i386 build (though lintian > OOMed there). I've not performed cross builds since we know that those > are broken. You privately clarified that you meant cross toolchain builds (build = host != target) rather than cross builds (build != host = target). I also attempted building a cross toolchain for i386 on amd64. Such builds fail, because Build-Depends lack debhelper and therefore dh_clean fails. DEBHELPER_BUILD_DEP is never set when DEB_CROSS equals yes and therefore no debhelper dependency is emitted. This failure is unrelated to my patch. Therefore, my patch does not regress this aspect. > Do you need any artifacts? .debs? build logs? I think the patch is > pretty straight forward. Is there anything else you need? Helmut
Bug#1042482: multilib lsan packages: dysfunctional?
Control: tags -1 + patch
Hi Matthias,
On Sun, Jul 30, 2023 at 07:10:09AM +0200, Matthias Klose wrote:
> see src/libsanitizer/configure.tgt, it's unsupported, the empty packages
> don't hurt. Feel free to send a patch not to build these packages, tested
> please for amd64 and i386 builds, plus cross builds targeting these
> architectures.
Thank you for pointing there. A key insight there is that lsan does not
work for 32bit architectures at all. Therefore, we can entirely remove
the 32bit lsan multilib packages. Surprisingly, the lib64lsan0 package
is already commented, so we don't have to consider that. I've
implemented the requested change and performed a local native build on
amd64. I've also performed the requested i386 build (though lintian
OOMed there). I've not performed cross builds since we know that those
are broken.
Do you need any artifacts? .debs? build logs? I think the patch is
pretty straight forward.
Helmut
--- gcc-13-13.1.0/debian/changelog
+++ gcc-13-13.1.0/debian/changelog
@@ -1,3 +1,10 @@
+gcc-13 (13.1.0-9.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Delete 32bit liblsan packages. (Closes: #1042482)
+
+ -- Helmut Grohne Sun, 30 Jul 2023 10:49:50 +0200
+
gcc-13 (13.1.0-9) unstable; urgency=medium
* Update to git 20230720 from the gcc-13 branch (13.2 release candidate).
--- gcc-13-13.1.0/debian/control
+++ gcc-13-13.1.0/debian/control
@@ -596,17 +596,6 @@
LeakSanitizer (Lsan) is a memory leak detector which is integrated
into AddressSanitizer.
-Package: lib32lsan0
-X-DH-Build-For-Type: target
-Section: libs
-Architecture: amd64 ppc64 kfreebsd-amd64 s390x sparc64 x32 mipsn32 mipsn32el
mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 mips64r6el
-Priority: optional
-Depends: gcc-13-base (= ${gcc:Version}), ${dep:libcbiarch}, ${shlibs:Depends},
${misc:Depends}
-Conflicts: ${confl:lib32}
-Description: LeakSanitizer -- a memory leak detector (32bit)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-
#Package: lib64lsan`'LSAN_SO`'LS
#Section: ifdef(`TARGET',`devel',`libs')
#Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarch64_archs')
@@ -617,26 +606,6 @@
# LeakSanitizer (Lsan) is a memory leak detector which is integrated
# into AddressSanitizer.
-#Package: libn32lsan`'LSAN_SO`'LS
-#Section: ifdef(`TARGET',`devel',`libs')
-#Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarchn32_archs')
-#Priority: optional
-#Depends: BASELDEP, ${dep:libcbiarch}, ${shlibs:Depends}, ${misc:Depends}
-#BUILT_USING`'dnl
-#Description: LeakSanitizer -- a memory leak detector (n32)
-# LeakSanitizer (Lsan) is a memory leak detector which is integrated
-# into AddressSanitizer.
-
-Package: libx32lsan0
-X-DH-Build-For-Type: target
-Section: libs
-Architecture: amd64 i386
-Priority: optional
-Depends: gcc-13-base (= ${gcc:Version}), ${dep:libcbiarch}, ${shlibs:Depends},
${misc:Depends}
-Description: LeakSanitizer -- a memory leak detector (x32)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-
Package: libtsan2
X-DH-Build-For-Type: target
Section: libs
--- gcc-13-13.1.0/debian/control.m4
+++ gcc-13-13.1.0/debian/control.m4
@@ -2094,33 +2094,6 @@
into AddressSanitizer.
')`'dnl libdbg
-ifenabled(`lib32lsan',`
-Package: lib32lsan`'LSAN_SO`'LS
-TARGET_PACKAGE`'dnl
-Section: ifdef(`TARGET',`devel',`libs')
-Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarch32_archs')
-Priority: optional
-Depends: BASELDEP, ${dep:libcbiarch}, ${shlibs:Depends}, ${misc:Depends}
-Conflicts: ${confl:lib32}
-BUILT_USING`'dnl
-Description: LeakSanitizer -- a memory leak detector (32bit)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-
-ifenabled(`libdbg',`
-Package: lib32lsan`'LSAN_SO-dbg`'LS
-TARGET_PACKAGE`'dnl
-Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarch32_archs')
-Section: debug
-Priority: optional
-Depends: BASELDEP, libdep(lsan`'LSAN_SO,32,=), ${misc:Depends}
-BUILT_USING`'dnl
-Description: LeakSanitizer -- a memory leak detector (32 bit debug symbols)
- LeakSanitizer (Lsan) is a memory leak detector which is integrated
- into AddressSanitizer (empty package).
-')`'dnl libdbg
-')`'dnl lib32lsan
-
ifenabled(`lib64lsan',`
#Package: lib64lsan`'LSAN_SO`'LS
#Section: ifdef(`TARGET',`devel',`libs')
@@ -2144,110 +2117,6 @@
# into AddressSanitizer.
')`'dnl libdbg
')`'dnl lib64lsan
-
-ifenabled(`libn32lsan',`
-#Package: libn32lsan`'LSAN_SO`'LS
-#Section: ifdef(`TARGET',`devel',`libs')
-#Architecture: ifdef(`TARGET',`CROSS_ARCH',`biarchn32_archs')
-#Priority: optional
-#Depends: BASELDEP, ${dep:libcbiarch}, ${shlibs:Depends}, ${misc:Depends}
-#BUILT_USING`'dnl
-#Description: LeakSanitizer -- a memory leak detector (n32)
-# LeakSanitizer (Lsan) is a memory leak detector which is integrated
-# into AddressSanitizer.
-
-ifenabled(`libdbg',`
-#Package: libn32lsan`'LSAN_SO-dbg`'LS
-#Architecture: i
Bug#1042482: multilib lsan packages: dysfunctional?
Package: lib32lsan0,lib64lsan0,libx32lsan0
Version: 13.1.0-9
Severity: important
Hi Matthias,
I am a bit confused about lib*lsan0. These are support libraries for the
leak sanitizer, but the multilib ones are empty (and the package
description even says so). However, these packages don't seem to work.
$ printf "int main(){}" | gcc -fsanitize=leak -xc -
$ printf "int main(){}" | gcc -fsanitize=leak -xc - -m32
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/liblsan.so
when searching for -llsan
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/liblsan.a
when searching for -llsan
/usr/bin/ld: cannot find -llsan: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/13/liblsan.so
when searching for -llsan
collect2: error: ld returned 1 exit status
$
This is in unstable with gcc-multilib, libgcc-13-dev and lib32lsan0
installed. Another hint that something is wrong is a comparison with the
address sanitizer. lib32asan8 is non-empty and -fsanitize=address tends
to work with a multilib.
I conclude that this is not working as intended. At this point, the best
course of action from my point of view is removing the multilib lsan
packages as they evidently do not work at all. Do you agree?
Why did I look into this? The multilib lsan packages happen to ship
empty directories /usr/lib{32,64,x32}. These directories are technically
susceptible to loss due to the /usr-merge. Quite probably, these
directories can be removed from the binary packages without loss of
functionality (which?), but that effort is wasted if we end up removing
these packages altogether.
Helmut
Bug#1035521: gcc: broken liblto_plugin.so symlink
Package: gcc Version: 4:13.1.0-1 Severity: serious User: helm...@debian.org Usertags: rebootstrap Hi Matthias, $ ls -la usr/lib/bfd-plugins/liblto_plugin.so lrwxrwxrwx 1 0 0 43 May 1 09:22 liblto_plugin.so -> ../gcc/x86_64-linux-gnu/13/liblto_plugin.so $ ls -la usr/lib/gcc/x86_64-linux-gnu/13/liblto_plugin.so ls: cannot access 'usr/lib/gcc/x86_64-linux-gnu/13/liblto_plugin.so': No such file or directory $ ls -la usr/libexec/gcc/x86_64-linux-gnu/13/liblto_plugin.so -rwxr-xr-x 1 0 0 63952 Apr 27 11:28 usr/libexec/gcc/x86_64-linux-gnu/13/liblto_plugin.so $ The liblto_plugin.so symlink shipped by gcc is broken. For some reason, gcc-13 installs to usr/libexec rather than usr/lib, but the symlink does not take that move into account. Consequently, lto is broken in gcc-13. This affects e.g. building systemd. I think you need to change https://sources.debian.org/src/gcc-defaults/1.204/debian/rules/#L827 from /usr/lib/gcc/$(DEB_HOST_GNU_TYPE)/$(PV_GCC)/liblto_plugin.so /usr/lib/bfd-plugins/liblto_plugin.so \ to /usr/libexec/gcc/$(DEB_HOST_GNU_TYPE)/$(PV_GCC)/liblto_plugin.so /usr/lib/bfd-plugins/liblto_plugin.so \ Helmut
Bug#1034293: cross-instal-location.diff no longer applies
Source: gcc-13 Version: 13-20230411-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, cross-install-location.diff no longer applies. I'm attaching a fix for your convenience. Helmut diff --minimal -Nru gcc-13-13-20230411/debian/changelog gcc-13-13-20230411/debian/changelog --- gcc-13-13-20230411/debian/changelog 2023-04-11 14:08:31.0 +0200 +++ gcc-13-13-20230411/debian/changelog 2023-04-12 07:17:42.0 +0200 @@ -1,3 +1,10 @@ +gcc-13 (13-20230411-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix application of cross-install-location.diff. (Closes: #-1) + + -- Helmut Grohne Wed, 12 Apr 2023 07:17:42 +0200 + gcc-13 (13-20230411-1) experimental; urgency=medium * New upstream snapshot, taken from the trunk. diff --minimal -Nru gcc-13-13-20230411/debian/patches/cross-install-location.diff gcc-13-13-20230411/debian/patches/cross-install-location.diff --- gcc-13-13-20230411/debian/patches/cross-install-location.diff 2023-01-27 07:12:51.0 +0100 +++ gcc-13-13-20230411/debian/patches/cross-install-location.diff 2023-04-12 07:17:42.0 +0200 @@ -382,9 +382,9 @@ gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER) -libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) +libexecsubdir := $(libexecdir)/gcc-cross/$(target_noncanonical)/$(gcc_version) + INSTALL := @INSTALL@ INSTALL_PROGRAM := @INSTALL_PROGRAM@ INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s - AUTOCONF := @AUTOCONF@ --- a/src/libgm2/libm2cor/Makefile.am +++ b/src/libgm2/libm2cor/Makefile.am @@ -27,7 +27,7 @@ MAKEOVERRIDES= diff --minimal -Nru gcc-13-13-20230411/debian/target gcc-13-13-20230411/debian/target --- gcc-13-13-20230411/debian/target1970-01-01 01:00:00.0 +0100 +++ gcc-13-13-20230411/debian/target2023-04-12 07:17:15.0 +0200 @@ -0,0 +1 @@ +arm64
Bug#1032275: gcc-12-cross: gfortran-12-ARCH is missing Provides: virtual packages
Control: tags -1 + wontfix Control: close -1 Control: block 983600 by 666743 Hi Dima, On Thu, Mar 02, 2023 at 09:15:41AM -0800, Dima Kogan wrote: > Hi. This is the underlying cause of > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983600 Thank you for working on this and thank you for consulting with d-cross@l.d.o. > Installing libopenmpi-dev:foreign is impossible because it depends on > some virtual gfortran packages that the cross-compiler is not providing. > I see this: > > # dpkg --print-architecture > amd64 > > # dpkg --print-foreign-architectures > arm64 > > # apt install libopenmpi-dev:arm64 > ... > The following packages have unmet dependencies: >libopenmpi-dev:arm64 : Depends: gfortran-12:arm64 but it is not going to > be installed or >gfortran-mod-15:arm64 > > # apt show libopenmpi-dev:arm64 > Package: libopenmpi-dev:arm64 > Depends: gfortran-12 | gfortran-mod-15, ... > > So to install libopenmpi-dev:arm64 we need gfortran-mod-15. This is > provided by the native compiler: > > # apt show gfortran-12 | grep Provides > Provides: fortran95-compiler, gfortran-mod-15 > > But not by the cross compiler: > > # apt show gfortran-12-aarch64-linux-gnu | grep Provides > nothing printed Good summary of the problem. Thanks. > Should the cross-compiler Provide this? Or is libopenmpi-dev wrong to > Depend on it? If gfortran-- were to provide gfortran-mod-15, bad things were to happen. Provides inherit the Multi-Arch property, and since gfortran-- is M-A:foreign, so would be gfortran-mod-15 and that would mean that gfortran-12-sparc-linux-gnu would satisfy libopenmpi-dev:arm64, which is something we really don't want. The other alternative here is changing dependencies of libopenmpi-dev and while that sounds workable initially, it isn't immediately obvious what to change it to. Fortunately, the answer is already being worked on. libopenmpi-dev should Depends: gfortran-12-for-host as its first alternative. The minor downside is that gfortran-12-for-host doesn't exist (yet). Since gfortran-12-for-host will be M-A:same, it can indeed provide gfortran-mod-15 and thus solve the issue from the other side. The bug that adds -for-host is #666743. It needs desperately needs more people working on it, especially with reviewing and testing. For these reasons, I'm going to close this bug report and hope you agree. It really isn't actionable on the gcc side and #666743 should entirely solve the issue. Helmut
Bug#1032161: gcc-12 FTCBFS: -gm2 not found
Source: gcc-12 Version: 12.2.0-14 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs Hi Matthias, gcc-12 fails to cross build since gm2 was introduced as a frontend due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336 and we cannot make a dent on it, but recently it started failing way earlier. It now fails finding -gm2 (the cross compiler). This is due to Build-Depends relying on a particular gcc version (which is good) but failing to supply the version suffix to the build. As with many other frontends, we need to pass GM2_FOR_TARGET to the build. I'm attaching a patch for this particular issue and that moves us back to the previous one. Helmut diff --minimal -Nru gcc-12-12.2.0/debian/changelog gcc-12-12.2.0/debian/changelog --- gcc-12-12.2.0/debian/changelog 2023-01-08 10:12:42.0 +0100 +++ gcc-12-12.2.0/debian/changelog 2023-02-27 13:33:34.0 +0100 @@ -1,3 +1,10 @@ +gcc-12 (12.2.0-14.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Improve cross building: Pass GM2_FOR_TARGET. (Closes: #-1) + + -- Helmut Grohne Mon, 27 Feb 2023 13:33:34 +0100 + gcc-12 (12.2.0-14) unstable; urgency=medium * Update to git 20230108 from the gcc-12 branch. diff --minimal -Nru gcc-12-12.2.0/debian/rules2 gcc-12-12.2.0/debian/rules2 --- gcc-12-12.2.0/debian/rules2 2022-10-31 14:42:14.0 +0100 +++ gcc-12-12.2.0/debian/rules2 2023-02-27 13:33:34.0 +0100 @@ -125,7 +125,8 @@ GFORTRAN_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gfortran-$(BASE_VERSION) \ GOC_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gccgo-$(BASE_VERSION) \ GNAT_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gnat-$(BASE_VERSION) \ - GDC_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gdc-$(BASE_VERSION) + GDC_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gdc-$(BASE_VERSION) \ + GM2_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gm2-$(BASE_VERSION) endif ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_TARGET_GNU_TYPE))
Bug#1026206: g++-13: fails to compile #include due to __float128 vs fixincludes
Package: g++-13 Version: 13-20221214-1 Severity: serious Hi Matthias, thanks for pushing gcc-13 into experimental already. That leaves plenty of time to work on it. I've located a quite fundamental problem with it already: $ cat test.c++ #include $ g++-13 -c test.c++ In file included from /usr/include/stdio.h:430, from test.c++:1: /usr/include/x86_64-linux-gnu/bits/floatn.h:87:9: error: multiple types in one declaration 87 | typedef __float128 _Float128; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn.h:87:20: error: declaration does not declare anything [-fpermissive] 87 | typedef __float128 _Float128; |^ In file included from /usr/include/x86_64-linux-gnu/bits/floatn.h:120: /usr/include/x86_64-linux-gnu/bits/floatn-common.h:214:9: error: multiple types in one declaration 214 | typedef float _Float32; | ^ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:214:15: error: declaration does not declare anything [-fpermissive] 214 | typedef float _Float32; | ^~~~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:251:9: error: multiple types in one declaration 251 | typedef double _Float64; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:251:16: error: declaration does not declare anything [-fpermissive] 251 | typedef double _Float64; |^~~~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:268:9: error: multiple types in one declaration 268 | typedef double _Float32x; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:268:16: error: declaration does not declare anything [-fpermissive] 268 | typedef double _Float32x; |^ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:285:14: error: multiple types in one declaration 285 | typedef long double _Float64x; | ^~ /usr/include/x86_64-linux-gnu/bits/floatn-common.h:285:21: error: declaration does not declare anything [-fpermissive] 285 | typedef long double _Float64x; | ^ $ Jakub Jelinek kindly pointed out that bits/floatn.h and bits/floatn-common.h should be fixincluded. I can see that this is happening in a build log and that those fixed includes are not contained in any binary package. As such, this is not considered an upstream problem. I see that the packaging deletes include-fixed and fail to understand why that happens at this time. Do you have a better understanding? Helmut
Bug#1023785: gcc-12: add multilib-multiarch support for loongarch64
On Thu, Nov 10, 2022 at 02:01:02PM +0800, 张丹丹 wrote: > - Are there any missing? Please tell me. I confirm that gcc-12 fails stage3 without this patch and succeeds after applying it. Note that the patch no longer applies cleanly due to an empty line. Helmut
Bug#1023692: gcc-arm-linux-gnueabihf: Compiling anything with fails: error: '_Float128' is not supported on this target
Control: tags -1 + unreproducible On Tue, Nov 08, 2022 at 11:20:33AM -0800, Dima Kogan wrote: > Package: gcc-arm-linux-gnueabihf > Version: 4:12.2.0-1 > Severity: important > X-Debbugs-Cc: none, Dima Kogan > > Hi. I have a "tst.c" which has just one line: > > #include > > Cross-compiling it doesn't work: > > $ arm-linux-gnueabihf-gcc-12 -c -o tst.o tst.c > > In file included from tst.c:1: > /usr/include/bits/mathcalls-helper-functions.h:20:40: error: '_Float128' is > not supported on this target > 20 | __MATHDECL_ALIAS (int, __fpclassify,, (_Mdouble_ __value), > fpclassify) > |^ > /usr/include/bits/mathcalls-helper-functions.h:24:37: error: '_Float128' is > not supported on this target > 24 | __MATHDECL_ALIAS (int, __signbit,, (_Mdouble_ __value), signbit) > | ^ > /usr/include/bits/mathcalls-helper-functions.h:29:35: error: '_Float128' is > not supported on this target > 29 | __MATHDECL_ALIAS (int, __isinf,, (_Mdouble_ __value), isinf) > | ^ > /usr/include/bits/mathcalls-helper-functions.h:33:36: error: '_Float128' is > not supported on this target > 33 | __MATHDECL_ALIAS (int, __finite,, (_Mdouble_ __value), finite) > |^ > /usr/include/bits/mathcalls-helper-functions.h:37:35: error: '_Float128' is > not supported on this target > 37 | __MATHDECL_ALIAS (int, __isnan,, (_Mdouble_ __value), isnan) > | ^ > /usr/include/bits/mathcalls-helper-functions.h:41:37: error: '_Float128' is > not supported on this target > 41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y), > iseqsig); > | ^ > /usr/include/bits/mathcalls-helper-functions.h:41:52: error: '_Float128' is > not supported on this target > 41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y), > iseqsig); > |^ > /usr/include/bits/mathcalls-helper-functions.h:44:41: error: '_Float128' is > not supported on this target > 44 | __MATHDECL_ALIAS (int, __issignaling,, (_Mdouble_ __value), > issignaling) > | ^ > > This should work. No, this is totally broken. No package in Debian ships anything in /usr/include/bits/. If you have anything there, your system is broken rather than Debian. If you use a clean chroot, you shall see that this works. The interesting question now is where those files came from. Helmut
Bug#1020600: gcc: objc: remove unused binary-without-manpage lintian overrides
Source: gcc-12 Version: 12-20220319-1 Severity: wishlist Tags: patch Hi Matthias, during DC22, I promised to send some cleanup patches preparing for gcc-for-host. This is one of the. The objc/objc++ frontends don't contain any binaries as they reuse existing compiler binaries. As such, the lintian overrides binary-without-manpage are not useful and should be deleted. Deleting them now reduces the code churn for gcc-for-host. I'm attaching a patch for your convenience. Helmut >From 7e3722a05d8855d71c985706c8d503ba53562af5 Mon Sep 17 00:00:00 2001 From: Helmut Grohne Date: Fri, 27 Mar 2020 15:50:21 +0100 Subject: [PATCH] remove unused binary-without-manpage overrides gobjc-N and gobjc++-N don't contain any binaries on $PATH that would warrant a manual page. --- debian/rules.d/binary-objc.mk | 4 debian/rules.d/binary-objcxx.mk | 4 2 files changed, 8 deletions(-) diff --git a/debian/rules.d/binary-objc.mk b/debian/rules.d/binary-objc.mk index b5cd216..743bf52 100644 --- a/debian/rules.d/binary-objc.mk +++ b/debian/rules.d/binary-objc.mk @@ -36,10 +36,6 @@ $(binary_stamp)-objc: $(install_stamp) mkdir -p $(d_objc)/usr/share/lintian/overrides echo '$(p_objc) binary: hardening-no-pie' \ > $(d_objc)/usr/share/lintian/overrides/$(p_objc) -ifeq ($(GFDL_INVARIANT_FREE),yes) - echo '$(p_objc) binary: binary-without-manpage' \ - >> $(d_objc)/usr/share/lintian/overrides/$(p_objc) -endif debian/dh_doclink -p$(p_objc) $(p_xbase) diff --git a/debian/rules.d/binary-objcxx.mk b/debian/rules.d/binary-objcxx.mk index 4f6d8e1..e750cae 100644 --- a/debian/rules.d/binary-objcxx.mk +++ b/debian/rules.d/binary-objcxx.mk @@ -34,10 +34,6 @@ $(binary_stamp)-objcxx: $(install_stamp) mkdir -p $(d_objcx)/usr/share/lintian/overrides echo '$(p_objcx) binary: hardening-no-pie' \ > $(d_objcx)/usr/share/lintian/overrides/$(p_objcx) -ifeq ($(GFDL_INVARIANT_FREE),yes) - echo '$(p_objcx) binary: binary-without-manpage' \ - >> $(d_objcx)/usr/share/lintian/overrides/$(p_objcx) -endif debian/dh_rmemptydirs -p$(p_objcx) -- 2.37.2
Bug#1020599: gcc: objc: drop obsolete sparc-only conflict
Source: gcc-12
Version: 12-20220319-1
Severity: wishlist
Tags: patch
Hi Matthias,
during DC22, I promised to send some cleanup patches preparing for
gcc-for-host. This is one of them.
There is a conflict on the objc package that is only relevant to sparc,
but sparc support is discontinued. As such the conflict should be
dropped rather than moved around with the gcc-for-host patches. I'm
attaching a patch for your convenience.
Helmut
>From 5c93b56b9a8b758e459e636a0235b648d459590b Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Fri, 27 Mar 2020 15:31:00 +0100
Subject: [PATCH] drop obsolete sparc-only conflict
---
debian/control.m4 | 1 -
1 file changed, 1 deletion(-)
diff --git a/debian/control.m4 b/debian/control.m4
index 3328f9d..f5fcd8e 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -3360,7 +3360,6 @@ Priority: optional
Depends: BASEDEP, gcc`'PV`'TS (= ${gcc:Version}), ${dep:libcdev}, ${shlibs:Depends}, libidevdep(objc`'PV-dev,,=), ${misc:Depends}
Suggests: ${gobjc:multilib}, gcc`'PV-doc (>= ${gcc:SoftVersion}), libdbgdep(objc`'OBJC_SO-dbg),
Provides: objc-compiler`'TS
-ifdef(`__sparc__',`Conflicts: gcc`'PV-sparc64', `dnl')
BUILT_USING`'dnl
Description: GNU Objective-C compiler
This is the GNU Objective-C compiler, which compiles
--
2.37.2
Bug#1010364: libffi overrides DEB_BUILD_OPTIONS=nocheck
Source: libffi Version: 3.4.2-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I see that you made libffi override DEB_BUILD_OPTIONS=nocheck in certain situations. I think your override is too broad as it also covers cross builds. I'm attaching a patch that narrows down your override to native builds only and I think it still covers the intended use (as you explained in the commend). What do you think? Helmut diff --minimal -Nru libffi-3.4.2/debian/changelog libffi-3.4.2/debian/changelog --- libffi-3.4.2/debian/changelog 2022-01-17 11:37:08.0 +0100 +++ libffi-3.4.2/debian/changelog 2022-04-29 17:59:05.0 +0200 @@ -1,3 +1,10 @@ +libffi (3.4.2-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Don't override DEB_BUILD_OPTIONS=nocheck for cross builds. Closes: #-1. + + -- Helmut Grohne Fri, 29 Apr 2022 17:59:05 +0200 + libffi (3.4.2-4) unstable; urgency=medium * Configure --without-gcc-arch. Closes: #995223. diff --minimal -Nru libffi-3.4.2/debian/rules libffi-3.4.2/debian/rules --- libffi-3.4.2/debian/rules 2022-01-17 11:37:06.0 +0100 +++ libffi-3.4.2/debian/rules 2022-04-29 17:59:03.0 +0200 @@ -26,7 +26,7 @@ with_check = yes else # override buildd admins to run the testsuite anyway ... - ifneq (,$(filter $(DEB_HOST_ARCH), m68k powerpcspe sh4)) + ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_HOST_ARCH), m68k powerpcspe sh4)) with_check = yes endif endif
Bug#1010330: gcc-12 fails to build a cross compiler: cross-fixes.diff no longer applies
Source: gcc-12 Version: 12-20220428-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, cross-fixes.diff no longer applies and that happens to break cross compiler builds. Please find a patch attached for your convenience. Helmut diff --minimal -Nru gcc-12-12-20220428/debian/changelog gcc-12-12-20220428/debian/changelog --- gcc-12-12-20220428/debian/changelog 2022-04-28 20:10:12.0 +0200 +++ gcc-12-12-20220428/debian/changelog 2022-04-29 06:54:13.0 +0200 @@ -1,3 +1,10 @@ +gcc-12 (12-20220428-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix application of cross-fixes.diff. (Closes: #-1) + + -- Helmut Grohne Fri, 29 Apr 2022 06:54:13 +0200 + gcc-12 (12-20220428-1) unstable; urgency=medium * New upstream snapshot, taken from the gcc-12 branch. diff --minimal -Nru gcc-12-12-20220428/debian/patches/cross-fixes.diff gcc-12-12-20220428/debian/patches/cross-fixes.diff --- gcc-12-12-20220428/debian/patches/cross-fixes.diff 2021-07-28 17:26:48.0 +0200 +++ gcc-12-12-20220428/debian/patches/cross-fixes.diff 2022-04-29 06:54:04.0 +0200 @@ -9,20 +9,16 @@ --- a/src/libgcc/config/ia64/fde-glibc.c +++ b/src/libgcc/config/ia64/fde-glibc.c -@@ -28,6 +28,7 @@ +@@ -28,8 +28,8 @@ #ifndef _GNU_SOURCE #define _GNU_SOURCE 1 #endif +#ifndef inhibit_libc #include "config.h" +-ifndef inhibit_libc #include #include -@@ -159,3 +160,5 @@ _Unwind_FindTableEntry (void *pc, unw_wo - - return data.ret; - } -+ -+#endif + #include --- a/src/libgcc/config/ia64/unwind-ia64.c +++ b/src/libgcc/config/ia64/unwind-ia64.c @@ -26,6 +26,7 @@
Bug#1009286: gcc-12: DEB_STAGE=rtlibs should include libatomic
Source: gcc-12 Version: 12-20220319-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I think DEB_STAGE=rtlibs should include libatomic. This is not currently the case and it causes issues. The cross compiler build normally includes e.g. libatomic1-riscv64-cross and when building e.g. zstd, it generates symbol uses for libatomic1, but dpkg-shlibdeps cannot locate libatomic.so.1, because dpkg-shlibdeps does not search /usr/riscv64-linux-gnu/lib. We need libatomic1:riscv64 here, which was disabled by DEB_STAGE=rtlibs. Please consider applying the attached patch. Helmut diff --minimal -Nru gcc-12-12-20220319/debian/changelog gcc-12-12-20220319/debian/changelog --- gcc-12-12-20220319/debian/changelog 2022-03-19 08:39:27.0 +0100 +++ gcc-12-12-20220319/debian/changelog 2022-04-11 06:06:01.0 +0200 @@ -1,3 +1,10 @@ +gcc-12 (12-20220319-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Do build libatomic for DEB_STAGE=rtlibs. (Closes: #-1) + + -- Helmut Grohne Mon, 11 Apr 2022 06:06:01 +0200 + gcc-12 (12-20220319-1) unstable; urgency=medium * New upstream snapshot, taken from the trunk. diff --minimal -Nru gcc-12-12-20220319/debian/rules.defs gcc-12-12-20220319/debian/rules.defs --- gcc-12-12-20220319/debian/rules.defs2022-02-25 11:18:28.0 +0100 +++ gcc-12-12-20220319/debian/rules.defs2022-04-11 06:06:01.0 +0200 @@ -1630,7 +1630,6 @@ with_hppa64 := $(call envfilt, hppa64, , , $(with_hppa64)) ifeq ($(DEB_STAGE),rtlibs) -with_libatomic := disabled for rtlibs stage with_libasan := disabled for rtlibs stage with_liblsan := disabled for rtlibs stage with_libtsan := disabled for rtlibs stage
Bug#1004683: gcc-12: cross-no-locale-include.diff no longer applies
Source: gcc-12 Version: 12-20220126-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, cross-no-locale-include.diff no longer applies, because the target file cppdefault.c was renamed to cppdefault.cc. This is easily fixed: sed -i -e 's/cppdefault\.c//' debian/patches/cross-no-locale-include.diff Helmut
Bug#1000459: gcc-12: cross-install-location.diff does not apply
Source: gcc-12 Version: 12-2027-1 Tags: patch User: helm...@debian.org Usertags: ftcbfs cross-install-location.diff does not apply due to changes in gcc. I'm attaching a patch to fix that. Can you apply it? I plan to send more fixes. Would you like to receive them in a different form (e.g. salsa merge requests)? Helmut --- a/debian/patches/cross-install-location.diff +++ b/debian/patches/cross-install-location.diff @@ -17,7 +17,7 @@ @@ -724,7 +724,7 @@ gcc_version := $(shell @get_gcc_base_ver @LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = $(srcdir)/gfortran.map @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.map-sun - gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h + gfor_c_HEADERS = ISO_Fortran_binding.h -gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include +gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ @@ -43,7 +43,7 @@ @@ -31,7 +31,7 @@ version_dep = endif - gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h + gfor_c_HEADERS = ISO_Fortran_binding.h -gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include +gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include
Bug#1000312: debugedit dropped Multi-Arch: foreign
Package: debugedit
Version: 1:5.0-2
Severity: important
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:binutils
During the debugedit split, debugedit somehow lost Multi-Arch: foreign.
As a consequence, binutils has become cross-bd-uninstallable and
architecture cross bootstrap has been broken. I think the annotation
should be reinstated.
Helmut
diff --minimal -Nru debugedit-5.0/debian/changelog
debugedit-5.0/debian/changelog
--- debugedit-5.0/debian/changelog 2021-11-18 08:55:04.0 +0100
+++ debugedit-5.0/debian/changelog 2021-11-21 12:11:50.0 +0100
@@ -1,3 +1,10 @@
+debugedit (1:5.0-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Re-add Multi-Arch: foreign to debugedit. Closes: #-1.
+
+ -- Helmut Grohne Sun, 21 Nov 2021 12:11:50 +0100
+
debugedit (1:5.0-2) unstable; urgency=medium
* Fix tests on hppa (Dave Anglin). Closes: #999845.
diff --minimal -Nru debugedit-5.0/debian/control debugedit-5.0/debian/control
--- debugedit-5.0/debian/control2021-10-01 11:08:31.0 +0200
+++ debugedit-5.0/debian/control2021-11-21 12:11:48.0 +0100
@@ -15,6 +15,7 @@
Package: debugedit
Architecture: any
+Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: tools for handling build-ids and paths rewriting in DWARF data
The debugedit project provides programs and scripts for creating
Bug#993503: gcc-11-base: coinstallation error for mipsel
Package: gcc-11-base Version: 11.2.0-3 Severity: serious Justification: dpkg unpack error gcc-11-base's changelog.Debian.gz is different on mipsel than everywhere else. Indeed, the version is duplicate in the changelog. As such, gcc-11-base:mipsel fails to coinstall with everything else despite being marked Multi-Arch: same. | Unpacking gcc-11-base:mipsel (11.2.0-3) ... | dpkg: error processing archive /tmp/apt-dpkg-install-kpSb1U/012-gcc-11-base_11.2.0-3_mipsel.deb (--unpack): | trying to overwrite shared '/usr/share/doc/gcc-11-base/changelog.Debian.gz', which is different from other instances of package gcc-11-base:mipsel The cause seems to be a binary upload. Any normal upload should fix this issue without further changes. Helmut
Bug#990257: libffi: update symbols for musl-linux-mips
Package: libffi Version: 3.3-6 Tags: ftbfs patch User: helm...@debian.org Usertags: rebootstrap libffi needs a symbol update to build for musl-linux-mips. As it happens, the symbols work like on mips. I think they're actually independent of the libc and kernel and therefore suggest replacing mips with any-mips. Here is a patch: sed -i -e 's/ !\(mips \)/ !any-\1/' debian/libffi7.symbols Helmut
Bug#989521: gcc-N: make ssp linking work on musl
Source: gcc-11
Version: 11.1.0-2
Tags: patch
X-Debbugs-Cc: Szabolcs Nagy , Rich Felker
I was looking into making the Debian packaging of gcc work with musl and
ran into issues with musl. Once enabling -fstack-protector-something,
linking tends to fail with missing symbols.
The reason is that musl enables TARGET_LIBC_PROVIDES_SSP, because its
libc.so provides the relevant ssp functions. No extra library needs to
be linked. What it does not provide though is libssp_nonshared.a. The
upstream gcc does not handle this situation and considers their presence
interlocked.
More background on this can be found at
https://www.openwall.com/lists/musl/2014/11/05/3.
Another issue is that any object compiled with
-fstack-protector-something makes it use a symbol from
libssp_nonshared.a, so the resulting link has to include -lssp_nonshared
regardless of whether a -fstack-protector-something is given.
The solution chosen by Alpine is changing LINK_SSP_SPEC to
unconditionally link "-lssp_nonshared", see
https://git.alpinelinux.org/aports/commit/?id=d307f133de1f8a9993ab0d6fd51176b9373df4c3.
Since Alpine is the largest musl user, following their lead seems
natural.
Once doing so, bootstrapping fails, because libbacktrace is built before
libssp and at that time there is no libssp_nonshared.a. However, it
isn't actually needed during bootstrap, because it's not built with
-fstack-protector-something. An empty libssp_nonshared.a would to to
make -lssp_nonshared happy there. So I propose injecting such an empty
library before the build. When someone enables ssp on gcc libraries,
this approach will break of course, but the breakage is already there
due to the missing ordering. Once the ordering is fixed upstream, my
workaround can be dropped without replacement.
Please consider applying the attached patch.
Helmut
diff --minimal -Nru gcc-11-11.1.0/debian/changelog
gcc-11-11.1.0/debian/changelog
--- gcc-11-11.1.0/debian/changelog 2021-05-08 13:50:11.0 +0200
+++ gcc-11-11.1.0/debian/changelog 2021-06-04 18:14:22.0 +0200
@@ -1,3 +1,10 @@
+gcc-11 (11.1.0-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix -fstack-protector on musl. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 04 Jun 2021 18:14:22 +0200
+
gcc-11 (11.1.0-2) experimental; urgency=medium
* Update to git 20210508 from the gcc-11 branch.
diff --minimal -Nru gcc-11-11.1.0/debian/patches/musl-ssp.diff
gcc-11-11.1.0/debian/patches/musl-ssp.diff
--- gcc-11-11.1.0/debian/patches/musl-ssp.diff 1970-01-01 01:00:00.0
+0100
+++ gcc-11-11.1.0/debian/patches/musl-ssp.diff 2021-06-04 18:14:16.0
+0200
@@ -0,0 +1,21 @@
+See
https://git.alpinelinux.org/aports/commit/?id=d307f133de1f8a9993ab0d6fd51176b9373df4c3
+and https://www.openwall.com/lists/musl/2014/11/05/3
+
+--- gcc-11-11.1.0.orig/src/gcc/gcc.c
gcc-11-11.1.0/src/gcc/gcc.c
+@@ -1087,8 +1087,15 @@
+
+ #ifndef LINK_SSP_SPEC
+ #ifdef TARGET_LIBC_PROVIDES_SSP
++#if DEFAULT_LIBC == LIBC_MUSL
++/* When linking without -fstack-protector-something but including objects that
++ were built with -fstack-protector-something, calls to
__stack_chk_fail_local
++ can be emitted. Thus -lssp_nonshared must be linked unconditionally. */
++#define LINK_SSP_SPEC "-lssp_nonshared"
++#else
+ #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
+ "|fstack-protector-strong|fstack-protector-explicit:}"
++#endif
+ #else
+ #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
+ "|fstack-protector-strong|fstack-protector-explicit" \
diff --minimal -Nru gcc-11-11.1.0/debian/rules.patch
gcc-11-11.1.0/debian/rules.patch
--- gcc-11-11.1.0/debian/rules.patch2021-05-02 09:17:25.0 +0200
+++ gcc-11-11.1.0/debian/rules.patch2021-06-04 18:11:17.0 +0200
@@ -61,6 +61,7 @@
pr87808 \
pr94253 \
gcc-arm-disable-guality-tests \
+ musl-ssp \
ifneq (,$(filter $(distrelease),precise xenial bionic focal groovy hirsute))
debian_patches += pr100067-revert
diff --minimal -Nru gcc-11-11.1.0/debian/rules2 gcc-11-11.1.0/debian/rules2
--- gcc-11-11.1.0/debian/rules2 2021-05-02 09:26:04.0 +0200
+++ gcc-11-11.1.0/debian/rules2 2021-06-04 18:10:24.0 +0200
@@ -1191,6 +1191,14 @@
rm -rf $(builddir)
mkdir $(builddir)
+ifneq (,$(filter musl-%,$(DEB_TARGET_ARCH)))
+ # We have to unconditionally link -lssp_nonshared on musl (see
+ # musl-ssp.diff). While gcc provides it, it comes a little late in the
+ # build for bootstrapping so we provide an empty one.
+ mkdir $(builddir)/gcc
+ ar rcs $(builddir)/gcc/libssp_nonshared.a
+endif
+
: # some tools like gettext are built with a newer libstdc++
mkdir -p bin
for i in msgfmt; do \
Bug#989205: gcc-11: update libasan symbols for riscv64
Source: gcc-11 Version: 10.2.1-6 Tags: patch User: helm...@debian.org Usertags: rebootstrap The libasan symbols do not match on riscv64 at present. Wrong symbols do not presently abort a native build, which is why it appears successful on the buildds. riscv64 is incorrectly recognized as a 32bit architecture. Please consider applying the attached patch to fix the symbols and the detection method. Helmut --- a/debian/libasan6.symbols +++ b/debian/libasan6.symbols @@ -1,7 +1,7 @@ libasan.so.6 libasan6 #MINVER# #include "libasan.symbols.common" -(arch=!arm64 !alpha !amd64 !ia64 !mips64el !ppc64 !ppc64el !s390x !sparc64 !kfreebsd-amd64)#include "libasan.symbols.32" -(arch=arm64 alpha amd64 ia64 mips64el ppc64 ppc64el s390x sparc64 kfreebsd-amd64)#include "libasan.symbols.64" +(arch-bits=32)#include "libasan.symbols.32" +(arch-bits=64)#include "libasan.symbols.64" (arch=armel armhf sparc64 x32)#include "libasan.symbols.16" # these are missing on some archs ... (arch=!s390x)__interceptor___tls_get_addr@Base 5
Bug#989158: libffi: update symbols for musl-linux-mipsel
Source: libffi Version: 3.3-6 Tags: patch User: helm...@debian.org Usertags: rebootstrap libffi needs a symbol update to build for musl-linux-mipsel. As it happens, the symbols work like on mipsel. I think they're actually independent of the libc and kernel and therefore suggest replacing mipsel with any-mipsel. Here is a patch: sed -i -e s/mipsel/any-mipsel/ debian/libffi7.symbols Helmut
Bug#988847: gcc-11: reduce Build-Depends of stage1
Source: gcc-11 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I noticed that building a stage1 cross compiler does not issue exactly the right Build-Depends. rebootstrap has traditionally ignored gcc's Build-Depends and just installed what it thinks was right, but maybe that's not the best of solutions. In particular, gcc Build-Depends on a pile of glibc stuff, which is quite obviously unavailable when building stage1. I'm attaching a patch that drops these unused dependencies. Please consider applying it. Helmut --- a/debian/control.m4 +++ b/debian/control.m4 @@ -68,7 +68,7 @@ LIBC_BUILD_DEP, LIBC_BIARCH_BUILD_DEP kfreebsd-kernel-headers (>= 0.84) [kfreebsd-any], linux-libc-dev [m68k], dwz, LIBUNWIND_BUILD_DEP LIBATOMIC_OPS_BUILD_DEP AUTO_BUILD_DEP - SOURCE_BUILD_DEP CROSS_BUILD_DEP + SOURCE_BUILD_DEP CROSS_BUILD_DEP dnl ISL_BUILD_DEP MPC_BUILD_DEP MPFR_BUILD_DEP GMP_BUILD_DEP, libzstd-dev, zlib1g-dev, gawk, lzma, xz-utils, patchutils, pkg-config, libgc-dev, --- a/debian/rules.conf +++ b/debian/rules.conf @@ -384,6 +384,10 @@ endif endif +ifeq ($(DEB_STAGE),stage1) + LIBC_BUILD_DEP := +endif + # needed for the include/asm symlink to run the testsuite for # non default multilibs ifneq (,$(multilib_archs)) @@ -391,8 +395,12 @@ endif LIBUNWIND_DEV_DEP := libunwind8-dev$(LS)$(AQ) -LIBUNWIND_BUILD_DEP := $(LIBUNWIND_DEV_DEP) [ia64], -LIBATOMIC_OPS_BUILD_DEP := libatomic-ops-dev$(LS) [ia64], +LIBUNWIND_BUILD_DEP := +LIBATOMIC_OPS_BUILD_DEP := +ifneq ($(DEB_STAGE),stage1) + LIBUNWIND_BUILD_DEP += $(LIBUNWIND_DEV_DEP) [ia64], + LIBATOMIC_OPS_BUILD_DEP += libatomic-ops-dev$(LS) [ia64], +endif ifneq ($(DEB_TARGET_ARCH),ia64) LIBUNWIND_DEV_DEP := # nothing else ifneq (,$(filter $(DEB_STAGE),stage1 stage2)) @@ -592,6 +600,9 @@ ifneq (,$(findstring cross-build-,$(build_type))) CROSS_BUILD_DEP += zlib1g-dev$(cross_lib_arch), libmpfr-dev$(cross_lib_arch), endif +ifeq ($(DEB_STAGE),stage1) + CROSS_BUILD_DEP := +endif SOURCE_BUILD_DEP := ifeq (,$(findstring gcc,$(PKGSOURCE))) SOURCE_BUILD_DEP := gcc-$(BASE_VERSION)-source (>= $(GCC_SOURCE_VERSION)), gcc-$(BASE_VERSION)-source (<< $(NEXT_GCC_SOURCE_VERSION)),
Bug#988008: mpfr4 FTBFS on musl-linux-arm64: symbol differences
Control: clone -1 -2 Control: retitle -2 mpfr4 FTBFS on musl-linux-armhf: symbol differences On Mon, May 03, 2021 at 05:44:49PM +0200, Helmut Grohne wrote: > mpfr4 fails to build from source on musl-linux-arm64 due to symbol > differences. mpfr4 has a number of symbols that happen to be > architecture dependent including some for arm64 (glibc). Those happen to > not be libc-dependent so the conditionalization should be extended to > non-glibc as is already done for e.g. amd64. Please consider running the > following sed command in the source tree to update the symbol file: > > sed -i -e '/^ /s/arm64/any-&/' debian/libmpfr6.symbols There is a similar issue for musl-linux-armhf. The corresponding fix is: sed -i -e '/^ /s/armhf/eabihf-any-any-arm/' debian/libmpfr6.symbols Helmut
Bug#988008: mpfr4 FTBFS on musl-linux-arm64: symbol differences
Source: mpfr4 Version: 4.1.0-3 Tags: ftbfs patch User: helm...@debian.org Usertags: rebootstrap mpfr4 fails to build from source on musl-linux-arm64 due to symbol differences. mpfr4 has a number of symbols that happen to be architecture dependent including some for arm64 (glibc). Those happen to not be libc-dependent so the conditionalization should be extended to non-glibc as is already done for e.g. amd64. Please consider running the following sed command in the source tree to update the symbol file: sed -i -e '/^ /s/arm64/any-&/' debian/libmpfr6.symbols Helmut
Bug#984456: RM: gcc-cross-support/experimental -- ROM; implemented by gcc-defaults
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-gcc@lists.debian.org Dear ftp master, please remove the source package gcc-cross-support and all of its binary packages from experimental. gcc-cross-support was meant as a proof-of-concept for showcasing where we're headed. This now causes issues with gcc-defaults providing the same packages, which is a good thing. We're not quite there yet, but I think at this point, the concept is well understood and the package serves no useful purpose anymore. Helmut
Re: Bug#982868: dpkg-cross generates erronous conflicts on like libc6-amd64:x32-i386-cross
Control: tags -1 + patch
Control: severity -1 serious
Control: clone -1 -2
Control: reassign -2 src:cross-toolchain-base
On Mon, Feb 15, 2021 at 06:01:45PM +0100, Julian Andres Klode wrote:
> Package: libc6-amd64-i386-cross
> Conflicts: libc0.1-i386-i386-cross, libc6-amd64:x32-i386-cross,
>
> The second one is wrong.
Yes, the mangling of arch qualified dependencies is wrong. The cross
suffix is appended to the architecture rather than the package name. I'm
attaching a patch that makes it correctly process arch qualified
dependencies.
> Would be good to get fixed, is RC if those conflicts are really
> needed, but otherwise marking it as important, since not sure.
I concur that it should be fixed for bullseye and thus raise the
severity to serious. Wookey, please downgrade if you disagree.
I'm also cloning a bug for c-t-b as it vendors dpkg-cross including this
bug.
Helmut
diff --minimal -Nru dpkg-cross-2.6.15/debian/changelog
dpkg-cross-2.6.15/debian/changelog
--- dpkg-cross-2.6.15/debian/changelog 2020-06-22 05:55:01.0 +0200
+++ dpkg-cross-2.6.15/debian/changelog 2021-02-15 17:36:34.0 +0100
@@ -1,3 +1,9 @@
+dpkg-cross (2.6.15-3.2) UNRELEASED; urgency=medium
+
+ * Fix converstion of arch qualified relations. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 15 Feb 2021 17:36:34 +0100
+
dpkg-cross (2.6.15-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru dpkg-cross-2.6.15/dpkg-cross dpkg-cross-2.6.15/dpkg-cross
--- dpkg-cross-2.6.15/dpkg-cross2020-06-21 21:28:46.0 +0200
+++ dpkg-cross-2.6.15/dpkg-cross2021-02-15 17:36:34.0 +0100
@@ -1358,7 +1358,12 @@
my $name = $1;
return () if grep { $_ eq $name } @removedeps;
return $str if grep { $_ eq $name } @keepdeps;
- $str =~ s/^([^ (]+)/$name-$arch-cross/;
+ if ($name =~ /^([^:]*):(.*)/) {
+ my $replacement = "$1-$2-cross";
+ $str =~ s/^[^ (]+/$replacement/;
+ } else {
+ $str =~ s/^([^ (]+)/$name-$arch-cross/;
+ }
return $str;
}
Bug#982765: libffi: update symbols for nios2
Source: libffi Version: 3.3-5 Tags: patch User: helm...@debian.org Usertags: rebootstrap Please update symbols for nios2. I'm applying the relevant changes as a .debdiff. Helmut diff --minimal -Nru libffi-3.3/debian/changelog libffi-3.3/debian/changelog --- libffi-3.3/debian/changelog 2020-11-11 17:12:05.0 +0100 +++ libffi-3.3/debian/changelog 2021-02-12 17:53:33.0 +0100 @@ -1,3 +1,10 @@ +libffi (3.3-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Update nios2 symbols. Closes: #-1. + + -- Helmut Grohne Fri, 12 Feb 2021 17:53:33 +0100 + libffi (3.3-5) unstable; urgency=medium * Bump standards and debhelper version. diff --minimal -Nru libffi-3.3/debian/libffi7.symbols libffi-3.3/debian/libffi7.symbols --- libffi-3.3/debian/libffi7.symbols 2020-11-11 17:12:05.0 +0100 +++ libffi-3.3/debian/libffi7.symbols 2021-02-12 17:53:31.0 +0100 @@ -1,6 +1,6 @@ libffi.so.7 libffi7 #MINVER# (symver)LIBFFI_BASE_7.0 3.3~20180313 (symver)LIBFFI_CLOSURE_7.0 3.3~20180313 - (symver|arch=!hppa !ia64 !m68k !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20180313 - (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313 + (symver|arch=!hppa !ia64 !m68k !nios2 !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20180313 + (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313 (symver)LIBFFI_BASE_7.1 3.3~20180313
Bug#916376: closed by Debian FTP Masters (Bug#954831: Removed package(s) from unstable)
Control: reopen -1 Control: reassign -1 gfortran-11 On Sat, Feb 13, 2021 at 01:09:30PM +, Debian Bug Tracking System wrote: > as the package gcc-8 has just been removed from the Debian archive > unstable we hereby close the associated bug reports. We are sorry > that we couldn't deal with your issue properly. The issue persists in newer gcc releases. Helmut
Bug#892281: closed by Debian FTP Masters (Bug#954831: Removed package(s) from unstable)
Control: reopen -1 Control: reassign -1 src:gcc-11 On Sat, Feb 13, 2021 at 01:09:15PM +, Debian Bug Tracking System wrote: > as the package gcc-8 has just been removed from the Debian archive > unstable we hereby close the associated bug reports. We are sorry > that we couldn't deal with your issue properly. The issue persists in newer gcc releases. Helmut
Bug#982524: nmu: gcc-11_11-20210207-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-gcc@lists.debian.org nmu gcc-11_11-20210207-1 . ANY . experimental . -m "rebuild with downgraded binutils" binutils was downgraded from 2.36 to 2.35. As a consequence, sections with the "R" flag are no longer supported, but gcc still generates them. The compilation of the following program fails: __attribute__((used)) int i; A binNMU will make gcc-11 detect the absence of this feature. I request urgently handling this issue as gcc-11 is presently completely broken. Helmut
Bug#981930: libelf1: fails to install
Hi Norbert, On Sat, Feb 06, 2021 at 08:08:20PM +0900, Norbert Preining wrote: > > The bug you report is actually present in -1 already. > > Hmmm > > > The package is not unusable. It merely cannot be coinstalled. > > then why on earth did I have both arch (amd64, i386) installed on my > computer before? And in addition, downgrading to the versions in testing > did work without a hinch. This particular combination of architectures did work for that combination of builds. Other combinations were already broken in -1. > So no, sorry to say, but you are wrong. The previous -1 packages > **were** co-installable, and that bug did not occur. It did not affect you, but the bug was present in -1 already. > > It doesn't really fix it, because dh-strip-nondeterminism doesn't fix it > > yet. That's a separate bug report. > > Might be a bug induced by the almighty nodeteriminsim/reproducible > groups, but it does show up here. The bug wasn't induced by reproducible. Quite on the contrary. The bug was induced by the usage of Multi-Arch: same! The Debian implementation of Multi-Arch requires reproducibility even before the reproducible people started working on it. Reproducibility just is the cure here. > > Reverting the NMU doesn't help in any way. It's reproducibility issue. > > It **does**. I reverted to the version in testing without any problems. Yes, I do see that. However, you cannot reupload those binary packages to the archive. If you were reverting to the "working" version and performing a build, with luck you'd still be affected. It only depends on when the builds are performed and whether their timing is close enough. The -1 builds were lucky for your particular combination. > And whatever it is, if it is a reproducibility issue, I honestly don't > give a #$#$Y(#'$ about it when it breaks the system. It doesn't break your system. It just breaks coinstallation of libelf1. I don't think that coinstallation issues are considered release critical at this point, because it is not documented in policy. A sad state of affairs, I know. > Reproducibility is not the highest aim we are targetting, it is just a > tool. Exactly. > If it is broken, then dump it and ignore it, who cares (besides > some former Debian Majesty). Reproducibility isn't the thing that is broken here. Multi-Arch is. The "dump it" solution would have been removing Multi-Arch from libelf1. That "fix" would have caused apt to remove a lot of packages from your system. I don't think you'd be any happier. Please don't blame the reproducible people for any of this. They're the cure, not the problem. Helmut
Bug#981930: libelf1: fails to install
Control: forcemerge 981835 -1 On Fri, Feb 05, 2021 at 05:36:45PM +0900, Norbert Preining wrote: > Package: libelf1 > Version: 0.182+20210203-1.1 The bug you report is actually present in -1 already. > Severity: grave > Justification: renders package unusable The package is not unusable. It merely cannot be coinstalled. > Updates are impossible since the update, the NMU which is supposed to > fix the issue doesn't really fix it, I still get errors on installation: It doesn't really fix it, because dh-strip-nondeterminism doesn't fix it yet. That's a separate bug report. > Unpacking libelf1:i386 (0.182+20210203-1.1) over (0.182-3) ... > dpkg: error processing archive > /var/cache/apt/archives/libelf1_0.182+20210203-1.1_i386.deb (--unpack): >trying to overwrite shared > '/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo', which is different > from other instances of package libelf1:i386 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > > This is preventing the whole system updates as apt immediately bails > out. The NMU needs to be reverted or fixed ASAP. Reverting the NMU doesn't help in any way. It's reproducibility issue. It all depends on when the various architectures build. dh-strip-nondeterminism needs to be fixed and elfutils needs to be binNMUed after that. Helmut
Bug#981835: libelf1 violates Multi-Arch: same / unreproducible
Control: clone -1 -2
Control: retitle -2 handle gettext PO-Revision-Date
Control: reassign -2 libstrip-nondeterminism-perl
Control: block -1 by -2
On Thu, Feb 04, 2021 at 06:51:49PM +, Simon McVittie wrote:
> 0.182+20210203-1.1 doesn't seem to solve this as intended, and triggers
> a similar failure mode on a more frequently co-installed pair of
> architectures:
>
> $ apt-get download libelf1 libelf1:i386
> $ aunpack libelf1_0.182+20210203-1.1_amd64.deb
> $ aunpack libelf1_0.182+20210203-1.1_i386.deb
> $ diff -ru libelf1_0.182+20210203-1.1_*/usr/share/
> Binary files
> libelf1_0.182+20210203-1.1_amd64/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo
> and
> libelf1_0.182+20210203-1.1_i386/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo
> differ
> Binary files
> libelf1_0.182+20210203-1.1_amd64/usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo
> and
> libelf1_0.182+20210203-1.1_i386/usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo
> differ
Thank you. After a little longer irc discussion, we mostly concluded
that this should be stripped by dh_strip_nondeterminism for now.
It already fixes the POT-Creation-Date, but does not touch the
PO-Revision-Date, because this field usually is only changed by
translators. Unfortunately, there are also some "mechanical" translators
in the form of sed scripts copied from gettext using autotools. Those
translators are used to create the en@quot and en@boldquot locales.
Given that they are translated at build time, they PO-Revision-Date is
"now" and if they are not corrected, then we see what we see here.
I'm attaching a patch to dh-strip-nondeterminism. Can $someone upload it
real soon as the libelf1 breakage has a high impact here? Once uploaded,
we'll have to binNMU elfutils.
Helmut
--- strip-nondeterminism-1.10.0.orig/lib/File/StripNondeterminism/handlers/gettext.pm
+++ strip-nondeterminism-1.10.0/lib/File/StripNondeterminism/handlers/gettext.pm
@@ -82,17 +82,18 @@
my $trans_len = unpack($fmt, substr($buf, $trans_to + $i*8));
my $trans_offset = unpack($fmt, substr($buf, $trans_to + $i*8 + 4));
my $trans_msg = substr($buf, $trans_offset, $trans_len);
- next unless $trans_msg =~ m/^POT-Creation-Date: (.*)/m;
+ next unless $trans_msg =~ m/^(POT-Creation-Date|PO-Revision-Date): (.*)/m;
- my $pot_date = $1;
+ my $date_key = $1;
+ my $date_value = $2;
my $time;
- eval {$time = Time::Piece->strptime($pot_date, "%Y-%m-%d %H:%M%z");};
+ eval {$time = Time::Piece->strptime($date_value, "%Y-%m-%d %H:%M%z");};
next if $@;
next if $time <= $norm_time;
my $new_time = strftime("%Y-%m-%d %H:%M%z", gmtime($norm_time));
$trans_msg
- =~ s/\QPOT-Creation-Date: $pot_date\E/POT-Creation-Date: $new_time/;
+ =~ s/\Q$date_key: $date_value\E/$date_key: $new_time/;
next if length($trans_msg) != $trans_len;
$buf
Bug#981835: libelf1 violates Multi-Arch: same / unreproducible
Package: libelf1 Version: 0.182-3 Severity: important Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:iproute2 libelf1 is presently marked Multi-Arch: same, but coinstallation on e.g. amd64 + mipsel fails with a file conflict: | Unpacking libelf1:mipsel (0.182+20210203-1) ... | dpkg: error processing archive /tmp/apt-dpkg-install-rORIn3/121-libelf1_0.182+20210203-1_mipsel.deb (--unpack): | trying to overwrite shared '/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo', which is different from other instances of package libelf1:mipsel | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) At its core, this is a reproducible issue that can be easily solved by calling dh_strip_nondeterminism. Please fix this issue soon as the impact is high: * breaks rebootstrap * breaks cross building e.g. iproute2 * elfutils is not reproducible I'm hereby offering a NMU in case you're busy. Helmut diff --minimal -Nru elfutils-0.182/debian/changelog elfutils-0.182/debian/changelog --- elfutils-0.182/debian/changelog 2021-01-06 14:05:13.0 +0100 +++ elfutils-0.182/debian/changelog 2021-02-04 13:05:58.0 +0100 @@ -1,3 +1,10 @@ +elfutils (0.182-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Make the build reproducible. (Closes: #-1) + + -- Helmut Grohne Thu, 04 Feb 2021 13:05:58 +0100 + elfutils (0.182-3) unstable; urgency=medium * Build with -flto-partition=none when building with -flto. diff --minimal -Nru elfutils-0.182/debian/rules elfutils-0.182/debian/rules --- elfutils-0.182/debian/rules 2021-01-04 11:28:41.0 +0100 +++ elfutils-0.182/debian/rules 2021-02-04 13:05:57.0 +0100 @@ -125,6 +125,7 @@ dh_dwz dh_strip + dh_strip_nondeterminism dh_compress dh_fixperms dpkg-gensymbols -Pdebian/libdw1/ -plibdw1 -c4
Bug#977959: gcc-11: update cross-install-location.diff for g++-mapper-server
Source: gcc-11 Version: 11-20201222-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Building cross compilers from gcc-11 presently fails, because it fails moving g++-mapper-server, which is expected in .../gcc-cross/... but is installed into .../gcc/ It seems like cross-install-location.diff needs an update. Please append the attached cross-install-location.diff to debian/patches/cross-install-location.diff. Helmut --- a/src/c++tools/Makefile.in +++ b/src/c++tools/Makefile.in @@ -21,7 +21,7 @@ libexecdir := @libexecdir@ target_noncanonical := @target_noncanonical@ gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER) -libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) +libexecsubdir := $(libexecdir)/gcc-cross/$(target_noncanonical)/$(gcc_version) INSTALL_PROGRAM := @INSTALL_PROGRAM@ INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s AUTOCONF := @AUTOCONF@
Bug#976875: elfutils: build profile pkg.elfutils.nodebuginfod broken
Source: elfutils Version: 0.180-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap The pkg.elfutils.nodebuginfod build profile broke with the introduction of libdebuginfod. I suggest also covering the library with the profile. Please consider applying the attached patch to that end. Helmut --- a/debian/rules +++ b/debian/rules @@ -46,6 +46,7 @@ ./configure $(confflags) --prefix=/usr \ --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \ --program-prefix=eu- --disable-silent-rules \ + --$(if $(filter pkg.elfutils.nodebuginfod,$(DEB_BUILD_PROFILES)),dis,en)able-libdebuginfod \ --$(if $(filter pkg.elfutils.nodebuginfod,$(DEB_BUILD_PROFILES)),dis,en)able-debuginfod build: build-stamp
Bug#973981: elfutils FTCBFS: missing native dependencies for libdebuginfod
Source: elfutils Version: 0.182-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs elfutils fails to cross build from source. It has two build passes, a native one and a cross one. The native one misses dependencies for libdebuginfod. As it turns out, we don't actually need a full libdebuginfod nor a debuginfod in that native pass at all. elfutils consinders this a bootstrap build and supports it via --enable-libdebuginfod=dummy. That's what the attached patch passes. Please consider applying it. Helmut diff --minimal -Nru elfutils-0.182/debian/changelog elfutils-0.182/debian/changelog --- elfutils-0.182/debian/changelog 2020-11-07 10:22:37.0 +0100 +++ elfutils-0.182/debian/changelog 2020-11-08 15:38:00.0 +0100 @@ -1,3 +1,11 @@ +elfutils (0.182-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: perform bootstrap build with dummy libdebuginfod and without +debuginfod. (Closes: #-1) + + -- Helmut Grohne Sun, 08 Nov 2020 15:38:00 +0100 + elfutils (0.182-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru elfutils-0.182/debian/rules elfutils-0.182/debian/rules --- elfutils-0.182/debian/rules 2020-11-07 10:22:37.0 +0100 +++ elfutils-0.182/debian/rules 2020-11-08 15:38:00.0 +0100 @@ -38,7 +38,8 @@ dh_autoreconf ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) ./configure --enable-maintainer-mode \ - --$(if $(filter pkg.elfutils.nodebuginfod,$(DEB_BUILD_PROFILES)),dis,en)able-debuginfod + --enable-libdebuginfod=dummy \ + --disable-debuginfod $(MAKE) $(MAKEFLAGS) $(MAKE) clean endif
Bug#666743: gcc-for-host fixes
Hi Matthias,
a while ago, you reviewed my last patch iteration and had a few remarks.
This is a summary of the remaining issues.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666743#65, you
complained about linking the doc directory of the new triple-suffixed
gdc package to the base package. In subsequent mails, I detailed why I
think this is not a problem.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666743#70, you
complained about missing package in dpkg-genchanges. This is due to a
wrong Architecture field fixed in 0001 attached. Thanks.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666743#85, you
complained about a loosely versioned dependeny on gdc fixed in 0002
attached. Thanks.
Thus this mail covers all remaining issues with two patches. I've based
them on your gcc-host branch as requested.
Helmut
>From fc5dda64d5903d7c6dcc6b695a3d2a2a7d8a727c Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Wed, 23 Sep 2020 21:50:56 +0200
Subject: [PATCH 1/2] fix architecture field of per-architecture packages
Reported-by: Matthias Klose
---
debian/control.m4 | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/debian/control.m4 b/debian/control.m4
index 9d85323..2659bf7 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -3354,7 +3354,7 @@ ifenabled(`objpp',`
ifenabled(`objppdev',`
for_each_arch(`
Package: gobjc++`'PV`'arch_gnusuffix
-Architecture: any
+Architecture: ifdef(`TARGET',`any',arch_deb)
Multi-Arch: foreign
Priority: optional
Depends: BASEDEP, gobjc`'PV`'arch_gnusuffix (= ${gcc:Version}), g++`'PV`'arch_gnusuffix (= ${gcc:Version}), ${shlibs:Depends}, libidevdep(objc`'PV-dev,,=), ${misc:Depends}
@@ -3404,7 +3404,7 @@ ifenabled(`objc',`
ifenabled(`objcdev',`
for_each_arch(`
Package: gobjc`'PV`'arch_gnusuffix
-Architecture: any
+Architecture: ifdef(`TARGET',`any',arch_deb)
Multi-Arch: foreign
Priority: optional
Depends: BASEDEP, gcc`'PV`'arch_gnusuffix (= ${gcc:Version}), ${dep:libcdev}, ${shlibs:Depends}, libidevdep(objc`'PV-dev,,=), ${misc:Depends}
@@ -3721,7 +3721,7 @@ ifenabled(`fortran',`
ifenabled(`fdev',`dnl
for_each_arch(`
Package: gfortran`'PV`'arch_gnusuffix
-Architecture: any
+Architecture: ifdef(`TARGET',`any',arch_deb)
Multi-Arch: foreign
Priority: optional
Depends: BASEDEP, gcc`'PV`'arch_gnusuffix (= ${gcc:Version}), libidevdep(gfortran`'PV-dev,,=), ${dep:libcdev}, ${shlibs:Depends}, ${misc:Depends}
@@ -5140,7 +5140,7 @@ Description: GNU Ada compiler (documentation)
ifenabled(`d ',`dnl
for_each_arch(`
Package: gdc`'PV`'arch_gnusuffix
-Architecture: any
+Architecture: ifdef(`TARGET',`any',arch_deb)
Multi-Arch: foreign
Priority: optional
Depends: SOFTBASEDEP, g++`'PV`'arch_gnusuffix (>= ${gcc:Version}), ${dep:gdccross}, ${dep:phobosdev}, ${shlibs:Depends}, ${misc:Depends}
@@ -5499,7 +5499,7 @@ Description: Phobos D standard library (debug symbols)
ifenabled(`m2 ',`dnl
for_each_arch(`
Package: gm2`'PV`'arch_gnusuffix
-Architecture: any
+Architecture: ifdef(`TARGET',`any',arch_deb)
Multi-Arch: foreign
Priority: optional
Depends: SOFTBASEDEP, g++`'PV`'arch_gnusuffix (>= ${gcc:Version}), ${dep:gm2cross}, libidevdep(gm2`'PV-dev,,=), ${shlibs:Depends}, ${misc:Depends}
--
2.28.0
>From b8139863760604abfe2c96688fa3e0bb28917fb2 Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Wed, 23 Sep 2020 21:52:34 +0200
Subject: [PATCH 2/2] fix version of gdc-N -> gdc-N-triplet dependency
Reported-by: Matthias Klose
---
debian/control.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control.m4 b/debian/control.m4
index 2659bf7..e837cb2 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -5158,7 +5158,7 @@ ifdef(`TARGET',`',`
Package: gdc`'PV
Architecture: any
Priority: optional
-Depends: gdc`'PV`'${target:suffix} (= ${gcc:SoftVersion}), SOFTBASEDEP, g++`'PV (>= ${gcc:SoftVersion}), ${dep:gdccross}, ${misc:Depends}
+Depends: gdc`'PV`'${target:suffix} (= ${gcc:Version}), SOFTBASEDEP, g++`'PV (>= ${gcc:SoftVersion}), ${dep:gdccross}, ${misc:Depends}
Provides: gdc, d-compiler, d-v2-compiler
Replaces: gdc (<< 4.4.6-5)
Description: GNU D compiler (version 2)
--
2.28.0
Bug#666743: draft implementation for a Multi-Arch: foreign interface to gcc
Hi Matthias, On Wed, Sep 23, 2020 at 05:52:47PM +0200, Matthias Klose wrote: > On 9/23/20 1:26 PM, Helmut Grohne wrote: > > Hi Matthias, > > > > thank you for reviewing my patch! > > > > On Wed, Sep 23, 2020 at 12:48:10PM +0200, Matthias Klose wrote: > >> looking at this patch: > >> > >> - dh_installdocs -p$(p_gdc) > >> - dh_installchangelogs -p$(p_gdc) src/gcc/d/ChangeLog > >> + debian/dh_doclink -p$(p_gdc_n) $(p_xbase) > >> > >> doesn't work, replacing the doc directory with a symlink. > > > > Please elaborate. > > > > p_gdc_n is a new package. Nothing is replaced here. > > > > The calls for p_gdc are not removed. They're moved lower. The docs stay > > right there where they are now. > > > > The new p_gdc_n package uses a symlink for its doc directory. That > > should be fine. > > ... which then doesn't work with a separate gdc build. I failed to figure out how a separate gdc would build at all. gdc-10-multilib also uses dh_doclink targeting p_xbase. So either the separate gdc build is broken already or it works with the additional p_xbase link here. In neither case, a change to the patch seems required. Helmut
Bug#666743: dpkg-genchanges warnings
Hi Matthias, thank you for reviewing my patch stack. On Wed, Sep 23, 2020 at 05:26:56PM +0200, Matthias Klose wrote: > you'll see warnings when dpkg-genchanges runs. looks like you want the > architecture file to list the one architecture explicitly, not list "any". Yes. I got this wrong. It's correct for cpp, gcc, and gccgo, but wrong for gfortran, gdc, gobjc, and gobjc++. Instead of `Architecture: any`, the correct line is: Architecture: ifdef(`TARGET',`any',arch_deb) Thank you for catching this. The next iteration shall fix it. Helmut
Bug#666743: draft implementation for a Multi-Arch: foreign interface to gcc
Hi Matthias, thank you for reviewing my patch! On Wed, Sep 23, 2020 at 12:48:10PM +0200, Matthias Klose wrote: > looking at this patch: > > - dh_installdocs -p$(p_gdc) > - dh_installchangelogs -p$(p_gdc) src/gcc/d/ChangeLog > + debian/dh_doclink -p$(p_gdc_n) $(p_xbase) > > doesn't work, replacing the doc directory with a symlink. Please elaborate. p_gdc_n is a new package. Nothing is replaced here. The calls for p_gdc are not removed. They're moved lower. The docs stay right there where they are now. The new p_gdc_n package uses a symlink for its doc directory. That should be fine. Helmut
Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev
On Sun, Aug 02, 2020 at 06:41:33PM +0200, Mark Wielaard wrote: > If it is convenient for Debian we can do a 0.181 release to make this > official. Thank you for the offer. I don't think that anything (in Debian) links libdebuginfod at present. Therefore we'll just make the library and the program optional with one flag (pkg.elfutils.nodebuginfod is what I propose as build profile name). We can revise build profiles at a later time if the need arises. In general, I don't like stub libraries. Bootstrapping is hard and you can easily get it wrong. A failure at one step sometimes manifests much later. Therefore we compare bootstrap builds with native builds using diffoscope. Having a stub library would show up as a giant difference. I'm not saying this cannot be done. I just want to avoid doing it as long as we can. I actually wonder more about why debuginfod must be merged into elfutils. To the uninitiated, it would seem that building debuginfod entirely separate should be possible. Simply separating debuginfod into a separate tarball (and source package in Debian) would have eliminated the need for the profile and --disable-debuginfod and likely more. Doing so might be difficult on the upstream side though and I'm not sure whether splitting debuginfod at release time would be practical. Very likely, you do have reasons for maintaining them together. This kinda is the same situation with util-linux. Splitting the libraries into a separate source tarball would make bootstrapping easier. There seems to be a trend in fusing components together. This also happened to udevd and systemd. Helmut
Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev
On Sun, Aug 02, 2020 at 12:58:49PM +0200, Matthias Klose wrote:
> please send a patch to build without libdebuginfod/debuginfod.
Attached.
Helmut
diff --minimal -Nru elfutils-0.180/debian/changelog
elfutils-0.180/debian/changelog
--- elfutils-0.180/debian/changelog 2020-07-16 19:34:22.0 +0200
+++ elfutils-0.180/debian/changelog 2020-08-02 14:43:31.0 +0200
@@ -1,3 +1,10 @@
+elfutils (0.180-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add pkg.elfutils.nodebuginfod build profile. (Closes: #966705)
+
+ -- Helmut Grohne Sun, 02 Aug 2020 14:43:31 +0200
+
elfutils (0.180-1) unstable; urgency=medium
* Transfer to team maintenance, add Kurt Roeckx and myself as uploaders.
diff --minimal -Nru elfutils-0.180/debian/control elfutils-0.180/debian/control
--- elfutils-0.180/debian/control 2020-07-16 19:34:22.0 +0200
+++ elfutils-0.180/debian/control 2020-08-02 14:43:31.0 +0200
@@ -12,8 +12,8 @@
libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel armhf arm64 sparc64
riscv64],
flex, bison,
pkg-config,
- libarchive-dev,
- libmicrohttpd-dev, libcurl4-gnutls-dev, libsqlite3-dev,
+ libarchive-dev ,
+ libmicrohttpd-dev , libcurl4-gnutls-dev
, libsqlite3-dev ,
Build-Conflicts: autoconf2.13
Standards-Version: 4.5.0
Section: libs
@@ -109,6 +109,7 @@
This package contains development libraries and header files for libasm1.
Package: libdebuginfod1
+Build-Profiles:
Architecture: any
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends},
@@ -121,6 +122,7 @@
This library is part of elfutils.
Package: libdebuginfod-dev
+Build-Profiles:
Section: libdevel
Architecture: any
Multi-Arch: same
@@ -132,6 +134,7 @@
libdebuginfod1.
Package: debuginfod
+Build-Profiles:
Section: devel
Architecture: any
Depends: libdebuginfod1 (= ${binary:Version}), ${shlibs:Depends},
${misc:Depends}
diff --minimal -Nru elfutils-0.180/debian/rules elfutils-0.180/debian/rules
--- elfutils-0.180/debian/rules 2020-07-16 19:34:22.0 +0200
+++ elfutils-0.180/debian/rules 2020-08-02 14:43:31.0 +0200
@@ -37,14 +37,15 @@
dh_testdir
dh_autoreconf
ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
- ./configure --enable-maintainer-mode
+ ./configure --enable-maintainer-mode --disable-debuginfod
$(MAKE) $(MAKEFLAGS)
$(MAKE) clean
endif
CFLAGS="$(CFLAGS) -O3" CXXFLAGS="-fpermissive" CPPFLAGS="$(CPPFLAGS)"
LDFLAGS="$(LDFLAGS)" \
./configure $(confflags) --prefix=/usr \
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
- --program-prefix=eu- --disable-silent-rules
+ --program-prefix=eu- --disable-silent-rules \
+ --$(if $(filter
pkg.elfutils.nodebuginfod,$(DEB_BUILD_PROFILES)),dis,en)able-debuginfod
build: build-stamp
build-stamp: config.status
Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev
Source: elfutils Version: 0.180-1 Severity: important User: helm...@debian.org Usertags: rebootstrap elfutils introduced a dependency loop. Please revert the libmicrohttpd-dev dependency now and discuss how it can be added back. Actual loop: src:elfutils libmicrohttpd-dev src:libmicrohttpd libcurl4-gnutls-dev src:curl libkrb5-dev src:krb5 libverto-dev src:libverto libglib2.0-dev src:glib2.0 libelf-dev src:elfutils It's quite a long loop. Maybe it can be broken elsewhere. Unfortunately, the current bootstrap uses all the other links, so we must revert libmicrohttpd-dev now and find another link to break first. Suggestions welcome. Helmut
Bug#965246: asan/vfork symbol issues
Source: gcc-10 Version: 10.1.0-6 Tags: patch User: helm...@debian.org Usertags: rebootstrap gcc-10 does not yet strictly validate symbols. It only does so when building cross compilers. While doing so, an architecture-specific issue regarding asan vfork symbols surfaced. The relevant symbols are listed universally, but are actually only available for some architectures. I'm attaching a patch to fix the symbols file to reflect that. The arch selector closely matches the ASAN_INTERCEPT_VFORK macro. Helmut diff --minimal -Nru gcc-10-10.1.0/debian/changelog gcc-10-10.1.0/debian/changelog --- gcc-10-10.1.0/debian/changelog 2020-07-14 12:07:51.0 +0200 +++ gcc-10-10.1.0/debian/changelog 2020-07-18 06:42:14.0 +0200 @@ -1,3 +1,10 @@ +gcc-10 (10.1.0-6.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix ASAN_INTERCEPT_VFORK related symbols. (Closes: #-1) + + -- Helmut Grohne Sat, 18 Jul 2020 06:42:14 +0200 + gcc-10 (10.1.0-6) unstable; urgency=medium * Update to git 20200714 from the gcc-10 branch. diff --minimal -Nru gcc-10-10.1.0/debian/libasan.symbols.common gcc-10-10.1.0/debian/libasan.symbols.common --- gcc-10-10.1.0/debian/libasan.symbols.common 2020-05-02 14:18:13.0 +0200 +++ gcc-10-10.1.0/debian/libasan.symbols.common 2020-07-18 06:41:15.0 +0200 @@ -600,7 +600,7 @@ __interceptor_ttyname_r@Base 7 __interceptor_valloc@Base 4.8 __interceptor_vasprintf@Base 5 - __interceptor_vfork@Base 10 + (arch=any-armel any-armhf any-arm64 any-i386 any-amd64)__interceptor_vfork@Base 10 __interceptor_vfprintf@Base 5 __interceptor_vfscanf@Base 4.8 __interceptor_vprintf@Base 5 @@ -1764,7 +1764,7 @@ ttyname_r@Base 7 valloc@Base 4.8 vasprintf@Base 5 - vfork@Base 10 + (arch=any-armel any-armhf any-arm64 any-i386 any-amd64)vfork@Base 10 vfprintf@Base 5 vfscanf@Base 4.8 vprintf@Base 5
Bug#963254: gcc-10: d/rules.def, set AQ to :all for cross build
On Tue, Jun 30, 2020 at 02:34:35PM +0800, YunQiang Su wrote: > No clear sense. > I just wonder that will conficts happen for native gcc:i686 conflict with > gcc-i686-linux-gnu:amd64? > if gcc-i686-linux-gnu:amd64 is marked as Multi-Arch:foreign. Well yes, there will be conflicts. Those conflicts are entirely independent of the M-A value though. You see gcc-i686-linux-gnu:amd64 will contain /usr/bin/i686-linux-gnu-gcc. gcc:i686 presently contains the same file. You cannot coinstall gcc-i686-linux-gnu:amd64 and gcc:i386 in any case. > And how about if multi foreign architecutures are added, for example: > i686> dpkg --add-architecutre amd64 arm64 ppc64el > ? Well, you install only one compiler targeting i386. You get to choose from which of these architectures you want to install the compiler. You can only install one package owning /usr/bin/i686-linux-gnu-gcc at a time. This seems pretty normal to me. What's the issue? Helmut
Bug#963254: gcc-10: d/rules.def, set AQ to :all for cross build
Control: clone -1 -2
Control: submitter -2 !
Control: reassign -2 dpkg-cross
Control: retitle -2 mark dpkg-crossed packages Multi-Arch: foreign
Control: tags -2 + patch
On Fri, Jun 26, 2020 at 02:12:46PM +0800, YunQiang Su wrote:
> Helmut Grohne 于2020年6月26日周五 上午5:11写道：
> > Did you actually try the patch to see whether it solves your problem?
>
> You patch cannot work:
>
> root@sid-i386:/build# dpkg -i
> gcc-10-i686-linux-gnu_10.1.0-4cross1_amd64.deb
> libgcc-10-dev-i386-cross_10.1.0-4cross1_all.deb
> Selecting previously unselected package gcc-10-i686-linux-gnu:amd64.
> (Reading database ... 42731 files and directories currently installed.)
> Preparing to unpack gcc-10-i686-linux-gnu_10.1.0-4cross1_amd64.deb ...
> Unpacking gcc-10-i686-linux-gnu:amd64 (10.1.0-4cross1) ...
> Selecting previously unselected package libgcc-10-dev-i386-cross.
> Preparing to unpack libgcc-10-dev-i386-cross_10.1.0-4cross1_all.deb ...
> Unpacking libgcc-10-dev-i386-cross (10.1.0-4cross1) ...
> dpkg: dependency problems prevent configuration of
> gcc-10-i686-linux-gnu:amd64:
> gcc-10-i686-linux-gnu:amd64 depends on libgcc-10-dev-i386-cross (>=
> 10.1.0-4cross1).
>
> dpkg: error processing package gcc-10-i686-linux-gnu:amd64 (--install):
> dependency problems - leaving unconfigured
> Setting up libgcc-10-dev-i386-cross (10.1.0-4cross1) ...
> Errors were encountered while processing:
> gcc-10-i686-linux-gnu:amd64
Thank you. You are correct. The patch cannot work as is. The patch can
only change the Multi-Arch field of tool packages, not for library
packages. Library packages should be Multi-Arch: same. However, we are
converting those architecture-dependent Multi-Arch: same packages to
libsomething-somearch-cross packages using dpkg-cross. And then they
become Multi-Arch: foreign. Since they, too, carry the architecture in
their name, they should be Multi-Arch: foreign as well. That's a pretty
simple change to dpkg-cross. So we need both patches in combination
here.
Could you try answering the other question from my mail about why the
Multi-Arch field would be harmful?
Helmut
diff --minimal -Nru dpkg-cross-2.6.15/dpkg-cross dpkg-cross-2.6.15/dpkg-cross
--- dpkg-cross-2.6.15/dpkg-cross2017-07-24 17:47:10.0 +0200
+++ dpkg-cross-2.6.15/dpkg-cross2020-06-26 17:52:45.0 +0200
@@ -1105,6 +1105,7 @@
print CONTROL "Section: " . $control{"section"} . "\n";
print CONTROL "Priority: extra\n";
print CONTROL "Architecture: all\n";
+ print CONTROL "Multi-Arch: foreign\n";
if (defined($control{"maintainer"})) {
print CONTROL "Maintainer: " . $control{"maintainer"} . "\n";
Bug#963254: gcc-10: d/rules.def, set AQ to :all for cross build
On Thu, Jun 25, 2020 at 09:49:01AM +0800, YunQiang Su wrote: > Helmut Grohne 于2020年6月24日周三 上午6:30写道： > > On Sun, Jun 21, 2020 at 09:10:48PM +0800, YunQiang Su wrote: > > > The major problem is Depends: libgcc-10-dev-i386-cross:amd64 (>= > > > 10.1.0-3cross1) but it is not installable > > > we need to mark gcc-10-i686-linux-gnu depends on > > > libgcc-10-dev-i386-cross:all to solve this problem. > > > > Can you try applying the attached patch? > > I don't think that mark gcc-N-triple as MA: foreign is a good idea. > It may confuse some user lot: will they try to install gcc-N-triple > from non-compliance arch? Can you elaborate on why you think this is not a good idea? In particular, #666743 will also include this change. The patch set has been there for quite a while. It would be high time comment on such an important aspect. I'm also confused about which users would be confused by the change. The idea is that it doesn't matter which gcc you install. apt will prefer the native one. What does "non-compliance" mean in this context? Did you actually try the patch to see whether it solves your problem? Helmut
Bug#963254: gcc-10: d/rules.def, set AQ to :all for cross build
Hi,
On Sun, Jun 21, 2020 at 09:10:48PM +0800, YunQiang Su wrote:
> The major problem is Depends: libgcc-10-dev-i386-cross:amd64 (>=
> 10.1.0-3cross1) but it is not installable
> we need to mark gcc-10-i686-linux-gnu depends on
> libgcc-10-dev-i386-cross:all to solve this problem.
Can you try applying the attached patch?
Helmut
diff --minimal -Nru gcc-10-10.1.0/debian/control gcc-10-10.1.0/debian/control
--- gcc-10-10.1.0/debian/control2020-05-15 15:11:57.0 +0200
+++ gcc-10-10.1.0/debian/control2020-06-24 00:17:56.0 +0200
@@ -265,6 +265,7 @@
Package: gcc-10-hppa64-linux-gnu
Architecture: hppa amd64 i386 x32
+Multi-Arch: foreign
Section: devel
Priority: optional
Depends: gcc-10-base (= ${gcc:Version}), gcc-10 (= ${gcc:Version}),
diff --minimal -Nru gcc-10-10.1.0/debian/control.m4
gcc-10-10.1.0/debian/control.m4
--- gcc-10-10.1.0/debian/control.m4 2020-05-11 13:38:42.0 +0200
+++ gcc-10-10.1.0/debian/control.m4 2020-06-24 00:17:56.0 +0200
@@ -107,6 +107,8 @@
ifelse(regexp(SRCNAME, `gcc-snapshot'),0,`dnl
Package: gcc-snapshot`'TS
Architecture: any
+ifelse(TS,`',`',`Multi-Arch: foreign
+')dnl
Section: devel
Priority: optional
Depends: binutils`'TS (>= ${binutils:Version}),
@@ -187,6 +189,8 @@
Package: gnat`'PV-base`'TS
Architecture: any
# "all" causes build instabilities for "any" dependencies (see #748388).
+ifelse(TS,`',`',`Multi-Arch: foreign
+')dnl
Section: libs
Priority: PRI(optional)
Depends: ${misc:Depends}
@@ -998,7 +1002,7 @@
ifenabled(`cdev',`
Package: gcc`'PV`'TS
Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -1037,7 +1041,7 @@
ifenabled(`multilib',`
Package: gcc`'PV-multilib`'TS
Architecture: ifdef(`TARGET',`any',MULTILIB_ARCHS)
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -1066,7 +1070,7 @@
ifenabled(`plugindev',`
Package: gcc`'PV-plugin-dev`'TS
Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -1082,8 +1086,7 @@
ifenabled(`cdev',`
Package: gcc`'PV-hppa64-linux-gnu
Architecture: ifdef(`TARGET',`any',hppa amd64 i386 x32)
-ifdef(`TARGET',`Multi-Arch: foreign
-')dnl
+Multi-Arch: foreign
Section: devel
Priority: PRI(optional)
Depends: BASEDEP, gcc`'PV`'TS (= ${gcc:Version}),
@@ -1097,7 +1100,7 @@
ifenabled(`cdev',`
Package: cpp`'PV`'TS
Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: ifdef(`TARGET',`devel',`interpreters')
Priority: optional
@@ -1148,7 +1151,7 @@
ifenabled(`c++dev',`
Package: g++`'PV`'TS
Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -1166,7 +1169,7 @@
ifenabled(`multilib',`
Package: g++`'PV-multilib`'TS
Architecture: ifdef(`TARGET',`any',MULTILIB_ARCHS)
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -3290,7 +3293,7 @@
ifenabled(`objppdev',`
Package: gobjc++`'PV`'TS
Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Priority: optional
Depends: BASEDEP, gobjc`'PV`'TS (= ${gcc:Version}), g++`'PV`'TS (=
${gcc:Version}), ${shlibs:Depends}, libidevdep(objc`'PV-dev,,=), ${misc:Depends}
@@ -3306,7 +3309,7 @@
ifenabled(`multilib',`
Package: gobjc++`'PV-multilib`'TS
Architecture: ifdef(`TARGET',`any',MULTILIB_ARCHS)
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -3325,7 +3328,7 @@
ifenabled(`objcdev',`
Package: gobjc`'PV`'TS
Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Priority: optional
Depends: BASEDEP, gcc`'PV`'TS (= ${gcc:Version}), ${dep:libcdev},
${shlibs:Depends}, libidevdep(objc`'PV-dev,,=), ${misc:Depends}
@@ -3341,7 +3344,7 @@
ifenabled(`multilib',`
Package: gobjc`'PV-multilib`'TS
Architecture: ifdef(`TARGET',`any',MULTILIB_ARCHS)
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -3629,7 +3632,7 @@
ifenabled(`fdev',`
Package: gfortran`'PV`'TS
Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Priority: optional
Depends: BASEDEP, gcc`'PV`'TS (= ${gcc:Version}),
libidevdep(gfortran`'PV-dev,,=), ${dep:libcdev}, ${shlibs:Depends},
${misc:Depends}
@@ -3647,7 +3650,7 @@
ifenabled(`multilib',`
Package: gfortran`'PV-multilib`'TS
Architecture: ifdef(`TARGET',`any',MULTILIB_ARCHS)
-ifdef(`TARGET',`Multi-Arch: foreign
+ifelse(TS,`',`',`Multi-Arch: foreign
')dnl
Section: devel
Priority: optional
@@ -3959,7 +3962,7 @@
ifenabled(`godev',`
Package: gccgo`'PV`'TS
Architecture: any
Bug#962677: mark g++-multilib-mipsel-linux-gnu and other multilibs Multi-Arch: foreign
Package: g++-multilib-mipsel-linux-gnu
Version: 1.185.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
In the absence of cross-translatable toolchain dependencies (#666743), a
workaround can be expanding Build-Depends. This is already used by e.g.
gcc-N and linux. If you apply this workaround to g++-multilib, it
becomes:
g++-multilib [mipsel] , g++-multilib-mipsel-linux-gnu [mipsel]
Unfortuntely, g++-multilib-mipsel-linux-gnu is not Multi-Arch tagged, so
a mipsel package is found, but there is none. The dependency is
unsatisfiable. Since the package name contains an architecture, it
really should be marked Multi-Arch: foreign.
mipsel is only an example here. It really works the same way for any
other architecture.
Please consider applying the attached patch.
Helmut
diff --minimal -Nru gcc-defaults-1.185.1/debian/changelog
gcc-defaults-1.185.1+nmu1/debian/changelog
--- gcc-defaults-1.185.1/debian/changelog 2019-09-09 14:30:14.0
+0200
+++ gcc-defaults-1.185.1+nmu1/debian/changelog 2020-06-11 18:07:43.0
+0200
@@ -1,3 +1,10 @@
+gcc-defaults (1.185.1+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark all cross tools Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Thu, 11 Jun 2020 18:07:43 +0200
+
gcc-defaults (1.185.1) unstable; urgency=medium
* Build the mipsel and mips64el cross packages from the
diff --minimal -Nru gcc-defaults-1.185.1/debian/control
gcc-defaults-1.185.1+nmu1/debian/control
--- gcc-defaults-1.185.1/debian/control 2019-09-09 14:30:14.0 +0200
+++ gcc-defaults-1.185.1+nmu1/debian/control2020-06-11 18:07:36.0
+0200
@@ -541,6 +541,7 @@
Package: gcc-multilib-x86-64-linux-gnu
Priority: optional
Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
Depends: cpp-x86-64-linux-gnu (= ${version:cpp}),
gcc-x86-64-linux-gnu (= ${version:gcc}),
gcc-${pv:gcc}-multilib-x86-64-linux-gnu ${reqv:gcc},
@@ -556,6 +557,7 @@
Package: g++-multilib-x86-64-linux-gnu
Priority: optional
Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
Depends: cpp-x86-64-linux-gnu (= ${version:cpp}),
g++-x86-64-linux-gnu (= ${version:gpp}),
gcc-multilib-x86-64-linux-gnu (= ${version:gcc}),
@@ -570,6 +572,7 @@
Package: gobjc-multilib-x86-64-linux-gnu
Priority: optional
Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
gobjc-x86-64-linux-gnu (>= ${version:gobjc}),
gcc-multilib-x86-64-linux-gnu (>= ${version:cpp}),
@@ -586,6 +589,7 @@
Package: gobjc++-multilib-x86-64-linux-gnu
Priority: optional
Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
gcc-multilib-x86-64-linux-gnu (>= ${version:cpp}),
gobjc++-x86-64-linux-gnu (>= ${version:gobjcxx}),
@@ -604,6 +608,7 @@
Package: gfortran-multilib-x86-64-linux-gnu
Priority: optional
Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
Depends: cpp-x86-64-linux-gnu (= ${version:cpp}),
gcc-multilib-x86-64-linux-gnu (= ${version:gcc}),
gfortran-x86-64-linux-gnu (= ${version:gfort}),
@@ -621,6 +626,7 @@
Package: gccgo-multilib-x86-64-linux-gnu
Priority: optional
Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
g++-multilib-x86-64-linux-gnu (>= ${version:gcc}),
gccgo-x86-64-linux-gnu (>= ${version:ggo}),
@@ -637,6 +643,7 @@
Package: gdc-multilib-x86-64-linux-gnu
Priority: optional
Architecture: arm64 i386 ppc64el x32
+Multi-Arch: foreign
Depends: cpp-x86-64-linux-gnu (>= ${version:cpp}),
gdc-${pv:gdc}-multilib-x86-64-linux-gnu ${reqv:gdc},
gdc-x86-64-linux-gnu (>= ${version:gdc}),
@@ -792,6 +799,7 @@
Package: gcc-multilib-s390x-linux-gnu
Priority: optional
Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
Depends: cpp-s390x-linux-gnu (= ${version:cpp}),
gcc-s390x-linux-gnu (= ${version:gcc}),
gcc-${pv:gcc}-multilib-s390x-linux-gnu ${reqv:gcc},
@@ -807,6 +815,7 @@
Package: g++-multilib-s390x-linux-gnu
Priority: optional
Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
Depends: cpp-s390x-linux-gnu (= ${version:cpp}),
g++-s390x-linux-gnu (= ${version:gpp}),
gcc-multilib-s390x-linux-gnu (= ${version:gcc}),
@@ -821,6 +830,7 @@
Package: gobjc-multilib-s390x-linux-gnu
Priority: optional
Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
Depends: cpp-s390x-linux-gnu (>= ${version:cpp}),
gobjc-s390x-linux-gnu (>= ${version:gobjc}),
gcc-multilib-s390x-linux-gnu (>= ${version:cpp}),
@@ -837,6 +847,7 @@
Package: gobjc++-multilib-s390x-linux-gnu
Priority: optional
Architecture: amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
Depends: cpp-s390x-linux-gnu (>= ${version:cpp}),
gcc-multilib-s390x-linux-gnu (>= ${version:cpp}),
gobjc++-s390x-linux-gnu (>= ${version:gobjcxx}),
@@ -855,6 +866,7 @@
P
Bug#960224: update symbols for mips64
Source: libffi Version: 3.3-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap libffi ftbfs for mips64 (big endian), because the symbols are wrong. Please update them using the attached patch. Helmut diff --minimal -Nru libffi-3.3/debian/changelog libffi-3.3/debian/changelog --- libffi-3.3/debian/changelog 2020-03-23 21:28:54.0 +0100 +++ libffi-3.3/debian/changelog 2020-05-10 21:29:50.0 +0200 @@ -1,3 +1,10 @@ +libffi (3.3-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Update mips64 symbols. (Closes: #-1) + + -- Helmut Grohne Sun, 10 May 2020 21:29:50 +0200 + libffi (3.3-4) unstable; urgency=medium * Update powerpc sysv assembly for ffi_powerpc.h changes (#541). diff --minimal -Nru libffi-3.3/debian/libffi7.symbols libffi-3.3/debian/libffi7.symbols --- libffi-3.3/debian/libffi7.symbols 2018-03-13 14:41:17.0 +0100 +++ libffi-3.3/debian/libffi7.symbols 2020-05-10 21:29:46.0 +0200 @@ -2,5 +2,5 @@ (symver)LIBFFI_BASE_7.0 3.3~20180313 (symver)LIBFFI_CLOSURE_7.0 3.3~20180313 (symver|arch=!hppa !ia64 !m68k !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20180313 - (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313 + (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313 (symver)LIBFFI_BASE_7.1 3.3~20180313
Bug#958909: gcc-10: fails to build sparc64 cross compiler with multilib
Source: gcc-10 Version: 10-20200411-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Control: block 881687 by -1 Control: affects -1 + src:gcc-9 In #881687, YunQiang Su sent a patch that disentangles multilibs in dpkg-cross for mipsen. The problem is that after dpkg-cross, the relevant ld.so paths end up conflicting and some need to be discarded. This issue also happens to affect sparc64 as both 32bit sparc and sparc64 use ld-linux.so.2. In order to make the patch from #881687 work for sparc64, support from gcc-N (also affects gcc-9 at least) is needed. Like it does for mipsen, it needs to pass the relevant -l flag to dh_shlibdeps. Please consider applying the attached patch to implement that. The bug log in #881687 is a little confusing, but the last mail from YunQiang Su should clear most confusion. Helmut --- a/debian/rules.defs +++ b/debian/rules.defs @@ -2245,6 +2245,8 @@ $(with_build_sysroot)/$(usr_lib64)) \ $(if $(findstring mipsn32,$(DEB_TARGET_ARCH)), \ $(with_build_sysroot)/$(usr_libn32)) \ + $(if $(filter sparc64,$(DEB_TARGET_ARCH)), \ + $(with_build_sysroot)/$(usr_lib64)) \ $(if $(filter yes,$(biarchsf) $(biarchhf)), \ $(with_build_sysroot)/usr/$(call mlib_to_march,$(2))/lib) \ $(if $(filter yes, $(with_common_libs)),, \
Bug#666743: draft implementation for a Multi-Arch: foreign interface to gcc
Control: reassign -1 src:gcc-10
Hi Matthias,
On Sun, Sep 30, 2018 at 02:46:04PM +0200, Helmut Grohne wrote:
> > - please complete the patch to cover all frontends. while these
> >might not be necessary for your bootstrap effort, I'd like to
> >have all frontends be covered in an uniform way.
>
> I've worked on this. It now covers cpp, cxx, d, fortran, gcc, go and
> objc. Notably, it does not cover ada, brig or objc++. ada looks
> complex. brig depends on hsail-tools, which is not Multi-Arch: foreign.
> So we cannot do brig at this time. objc++ looks manageable.
I've completed objc++, which was indeed easy. The new gm2 frontend is
also missing.
I've also split up the big patch into individual patches to make them
easier to use/review/select. The updated patch stack for gcc-10 is
applied. Beware that the patch stack introduces Breaks and Replaces. The
versions in these Breaks and Replaces is always "0TODO" or "999:0TODO"
and needs to be replaced with the version used for applying.
> > - for testing:
I've performed a regular build and inspected the resulting lintian
warnings and package contents.
I've also attempted building cross compilers using the patch stack by
adding the stack to a fork of rebootstrap.
I've not attempted cross building gcc with the patch stack, because
cross builds are known broken:
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336
* https://gcc.gnu.org/legacy-ml/gcc-help/2015-01/msg00111.html
Both of these issues are reproducible on gcc-9 and gcc-10 in unstable.
Moving forward:
There is more urgency for this feature now, because we need to run 64bit
executables for building larger packages on 32bit architectures. There
are two routes:
* Moving this stack forward and going Multi-Arch.
* Introducing yet another pile of compiler executables for this purpose
(YunQiang Su's appraoch).
I believe that the utility for any of these -for-host variants is very
limited except for c, cxx and fortran. I recommend not applying the
other patches (d, go, objc, objcxx), but I have attached them for
reference.
How to apply the patch stack:
0001: Only makes sense if you apply one of 0002, 0003, 0004, 0005, 0006,
0007, 0009, 0010 or 0011.
0002: cpp-$v-$triplet. Requires 0001. Update Breaks+Replaces.
0003: gcc-$v-$triplet. Requires 0001 and 0002. Updates Breaks+Replaces.
0004: g++-$v-$triplet. Requires 0001, 0002, and 0003. Update
Breaks+Replaces.
0005: gfortran-$v-$triplet. Requires 0001. Update Breaks+Replaces.
0006: gdc-$v-$triplet. Requires 0001. Update Breaks+Replaces.
0007: gccgo-$v-$triplet: Requires 0001. Update Breaks+Replaces.
0008: Cleanup. Consider applying right away.
0009: Cleanup. Consider applying right away.
0010: gobjc-$v-$triplet: Requires 0001 and 0009. Update Breaks+Replaces.
0011: gobjc++-$v-$triplet. Requires 0001, 0010 and 0011. Update
Breaks+Replaces.
I hope that this allows us to move forward. I've also Cced
debian-cross@l.d.o to elicit more review and testing.
Helmut
>From 069536e9afe1082c29a3b2da9e6f6b156f44e9fc Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Fri, 27 Mar 2020 06:32:46 +0100
Subject: [PATCH 01/11] add support code for gcc-for-host
control.m4 macro for_each_arch iterates over all known architectures and
substitutes arch_deb (the Debian architecture name), arch_gnu (the GNU
triplet) and arch_gnusuffix (a package name suffix encoding the
architecture) variables.
The substitution variable target:suffix can be used to interpolate the
current target architecture suffix for dependencies from the regular
tool packages on architecture-qualified tool packages.
---
debian/control.m4 | 7 +++
debian/rules.conf | 2 ++
2 files changed, 9 insertions(+)
diff --git a/debian/control.m4 b/debian/control.m4
index bbc71a2..94a9741 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -39,6 +39,13 @@ define(`BUILT_USING', ifelse(add_built_using,yes,`Built-Using: ${Built-Using}
'))
define(`TARGET_PACKAGE',`X-DH-Build-For-Type: target
')
+define(`_for_each',`ifelse(`$3',`',`',`pushdef(`$1',`$3')$2`'popdef(`$1')`'$0(`$1',`$2',shift(shift(shift($@')')
+define(`for_each_arch',`_for_each(`_arch',`dnl
+pushdef(`arch_deb',`patsubst(_arch,`=.*',`')')dnl
+pushdef(`arch_gnu',`patsubst(_arch,`.*=',`')')dnl
+pushdef(`arch_gnusuffix',`-patsubst(arch_gnu,`_',`-')')dnl
+$1`'popdef(`arch_gnusuffix')popdef(`arch_gnu')popdef(`arch_deb')',dnl
+patsubst(ARCH_GNUTYPE_MAP,`\s+',`,'))')
divert`'dnl
dnl --
diff --git a/debian/rules.conf b/debian/rules.conf
index 441c0e8..6149073 100644
--- a/debian/rules.conf
+++ b/debian/rules.conf
@@ -686,6 +686,7 @@ ctrl_flags += \
-DPHOBOS_BUILD_DEP="$(PHOBOS_BUILD_DEP)" \
-DGM2_BUILD_DEP="$(GM2_BUILD_DEP)" \
-DOFFLOAD_BUILD_DEP="$(OFFLOAD_BUILD_DEP)" \
+ -DARCH_GNUTYPE_MAP="$(arch_gnutype_map)" \
-DMULTILIB_ARCHS
Bug#928785: gcc-9: cross-install-location.diff no longer applies
Source: gcc-9 Version: 9.1.0-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I noticed that cross-install-location.diff no longer applies. The attached patch fixes that. Please let me know if you'd prefer a pull request on salsa. Helmut --- a/debian/patches/cross-install-location.diff +++ b/debian/patches/cross-install-location.diff @@ -18,8 +18,8 @@ @LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = $(srcdir)/gfortran.map @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.map-sun gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h --gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include -+gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include +-gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include ++gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ $(lt_host_flags) @@ -44,8 +44,8 @@ endif gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h --gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include -+gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include +-gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include ++gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ $(lt_host_flags)
Bug#926984: gnupg2 FTBFS with gcc-9: dirmngr/dns.h:1058:24: error: lvalue required as unary '&' operand
Source: gnupg2 Version: 2.2.15-1 Severity: important Tags: ftbfs patch upstream User: helm...@debian.org Usertags: rebootstrap gnupg2 fails to build from source with gcc-9, here is the relevant part of a cross build log: | aarch64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../dirmngr -I.. -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/lib/gnupg\"" -DGNUPG_LIBDIR=" | \"/usr/lib/aarch64-linux-gnu/gnupg\"" -DGNUPG_DATADIR="\"/usr/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/var\"" -Wdate-time -D_FORTIFY_SOURCE=2 | -std=gnu99 -I/usr/include/p11-kit-1 -Wall -Wno-pointer-sign -Wpointer-arith -g -O2 -fdebug-prefix-map=/tmp/buildd/gnupg2/gnupg2-2.2.13=. -fstack-protector-strong -Wformat -Werror | =format-security -c -o dns-stuff.o ../../dirmngr/dns-stuff.c | In file included from ../../dirmngr/dns-stuff.c:57: | ../../dirmngr/dns-stuff.c: In function 'libdns_res_open': | ../../dirmngr/dns.h:1058:24: error: lvalue required as unary '&' operand | 1058 | #define dns_opts(...) (_quietinit((struct dns_options)DNS_OPTS_INIT(__VA_ARGS__))) | |^ | ../../dirmngr/dns-stuff.c:719:23: note: in expansion of macro 'dns_opts' | 719 | dns_opts (.socks_host = _host, | | ^~~~ | make[4]: Leaving directory '/tmp/buildd/gnupg2/gnupg2-2.2.13/build/dirmngr' | make[4]: *** [Makefile:995: dns-stuff.o] Error 1 | make[3]: Leaving directory '/tmp/buildd/gnupg2/gnupg2-2.2.13/build' | make[3]: *** [Makefile:616: all-recursive] Error 1 | make[2]: Leaving directory '/tmp/buildd/gnupg2/gnupg2-2.2.13/build' | make[2]: *** [Makefile:536: all] Error 2 | dh_auto_build: cd build && make -j1 returned exit code 2 | make[1]: Leaving directory '/tmp/buildd/gnupg2/gnupg2-2.2.13' | make[1]: *** [debian/rules:55: override_dh_auto_build-arch] Error 2 | make: *** [debian/rules:35: binary-arch] Error 2 | dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 This problem also affects OE and Khem Raj has created a fix already: https://patchwork.openembedded.org/patch/157377/ Can you cherry-pick that patch? Helmut
Bug#925040: gcc-8 FTCBFS: builds idgen.c with the wrong compiler
Source: gcc-8 Version: 8.3.0-2 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap gcc-8 fails to cross build from source. http://crossqa.subdivi.de/build/gcc-8_8.3.0-2_ppc64el_20190301030546.log | powerpc64le-linux-gnu-g++-8 -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Id -I../../src/gcc -I../../src/gcc/d -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o d/idgen.dmdgen.o -MT d/idgen.dmdgen.o -MMD -MP -MF d/.deps/idgen.dmdgen.TPo -I../../src/gcc/d -I../../src/gcc/d/dfrontend -Id ../../src/gcc/d/dfrontend/idgen.c | g++-o d/idgen d/idgen.dmdgen.o | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21) | /usr/bin/ld: d/idgen.dmdgen.o: error adding symbols: file in wrong format | collect2: error: ld returned 1 exit status | make[4]: *** [../../src/gcc/d/Make-lang.in:312: d/idgen] Error 1 | make[4]: Leaving directory '/<>/build/gcc' | make[3]: *** [Makefile:4305: all-gcc] Error 2 | make[3]: Leaving directory '/<>/build' | make[2]: *** [Makefile:907: all] Error 2 | make[2]: Leaving directory '/<>/build' It uses the host architecture compiler to compile idgen.c and then tries to link it with the build architecture compiler. It really wants to run idgen, so using the build architecture compiler is correct. The attached patch fixes that and makes gcc-8 cross buildable. Please consider applying it. Helmut --- gcc-8-8.2.0.orig/src/gcc/d/Make-lang.in +++ gcc-8-8.2.0/src/gcc/d/Make-lang.in @@ -315,7 +315,7 @@ +$(LINKER_FOR_BUILD) $(BUILD_LINKER_FLAGS) $(BUILD_LDFLAGS) -o $@ $^ d/idgen.dmdgen.o: d/dfrontend/idgen.c - $(filter-out -fprofile-%,$(DMD_COMPILE)) $(D_INCLUDES) $< + $(filter-out -fprofile-%,$(DMDGEN_COMPILE)) $(D_INCLUDES) $< $(POSTCOMPILE) d/impcnvgen.dmdgen.o: $(srcdir)/d/dfrontend/impcnvgen.c
Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler
On Thu, Jan 24, 2019 at 04:38:19PM +0100, Helmut Grohne wrote:
> Ultimately, this means that marking binutils- M-A:foreign was
> wrong. It means that binutils plays the same role as ruby, perl, python
> and even make: you can load shared objects into it, but much of the time
> you don't. All of the other examples are M-A:allowed, so I guess
> binutils- needs to become M-A:allowed as well. Given that gcc
> Depends on binutils, binutils is M-A:no, and binutils Depends:
> binutils- without :any, the switch from M-A:foreign to
> M-A:allowed should fix this this bug, but at the same time it would
> break a fair number of use cases. We specifically have binutils-for-host
> to allow using foreign binutils. Likely binutils-for-host should
> Depends: binutils-:any then. On the flip side, that means that
> whenever you need plugins, you cannot use binutils-for-host.
>
> Now marking anything M-A:allowed is basically irreversible, because
> people are going to use :any and all those deps break when removing
> M-A:allowed. Therefore we should think hard about whether this is the
> right route. I've added debian-cross@l.d.o to Cc to elicit some
> feedback.
You can find the patch for binutils attached. binutils- will
become Multi-Arch: allowed. With this patch applied there are the
following ways to depend on binutils:
A Source package.
A.A You want binutils for the host architecture -> binutils-for-host
A.A You want binutils for the build architecture -> binutils-for-build
B Binary package of architecture $ARCH.
B.A You want binutils targeting the $ARCH.
B.A.A Your package contains a plugin to load into binutils ->
binutils-$ARCH
B.A.B No plugin -> binutils-$ARCH:any
B.B You want binutils targeting some executable architecture.
B.B.A Your package contains a plugin to load into binutils ->
binutils
B.B.B No plugin -> binutils-for-build
In #895251, I requested that gcc use triplet-prefixed tools to allow
coinstalling binutils. It also made the architecture of binutils opaque
(which is what this bug is about). After causing repeated problems, the
relevant change was finally reverted via #915194. Now gcc uses
unprefixed tools again. But it still prefers prefixed tools in
/usr/ (which is what this bug is about). We'll should change
that using triplet-prefixed tools explicitly at some point. gcc-8
presently Depends on "binutils". gcc-8- will have to Depends
binutils- without a :any. With the patch, binutils will Depends:
binutils- without :any, so using gcc-8:amd64 with
binutils-x86-64-linux-gnu:i386 will no longer be possible. So on the gcc
side, the attached patch will work.
src:arch-test uses binutils-, but it is Architecure: all, so it
pretty much doesn't matter whether the dependencies are annotated or
not.
src:cross-toolchain-base{,-port} conflicts with a number of
binutils-. That will continue to work.
src:gcc-8-cross (and similar packages) Build-Depends binutils-.
The binutils patch will render these dependencies cross-unsatisfiable.
They will need to be annotated :any or switched to binutils-for-host if
we want to cross build gcc-8-cross. Matthias, will you handle these?
src:linux Build-Depends binutils-. The binutils patch will
render these dependencies cross-unsatisfiable. They will need to be
switched to binutils-for-host or annotated with :any (after checking
that it doesn't use plugins). Maintainers Cced.
So the attached patch will break cross building of gcc and linux. It
won't break any native stuff and it'll fix the bug at hand.
Helmut
diff --minimal -Nru binutils-2.31.1/debian/changelog
binutils-2.31.1/debian/changelog
--- binutils-2.31.1/debian/changelog2019-02-27 22:30:21.0 +0100
+++ binutils-2.31.1/debian/changelog2019-03-19 14:25:35.0 +0100
@@ -1,3 +1,13 @@
+binutils (2.31.1-15.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ * Demote binutils- from Multi-Arch: foreign to Multi-Arch: allowed.
+ (Closes: #920286)
+ * Let binutil-for-host Depends: binutils-:any.
+
+ -- Helmut Grohne Tue, 19 Mar 2019 14:25:35 +0100
+
binutils (2.31.1-15) unstable; urgency=high
* Fix PR ld/24276, taken from the trunk. Closes: #923246.
diff --minimal -Nru binutils-2.31.1/debian/control
binutils-2.31.1/debian/control
--- binutils-2.31.1/debian/control 2019-02-19 13:39:31.0 +0100
+++ binutils-2.31.1/debian/control 2019-03-19 14:25:22.0 +0100
@@ -34,7 +34,7 @@
Package: binutils-for-host
Architecture: any
-Depends: ${binutils:native} (>= ${binutils:minver}),
+Depends: ${binutils:native}:any (>= ${binutils:minver}),
binutils-common (= ${binary:Version}),
Multi-Arch: same
Description: GNU assembler, linker and binary utilities for the host
architecture
@@ -192,7 +192,7 @@
Package: binutils-x86-64-linux-gnu
Priority: optional
Architecture: amd64 arm64 i386 ppc64el x32
Bug#924325: gcc-8-cross: FTBFS for unknown reasons
On Mon, Mar 11, 2019 at 04:34:35PM +, Santiago Vila wrote: > Status: failed gcc-8-cross_26_amd64-20190309T042203.371Z I've looked at the log and found a more useful bit: | ../../gnatbind -I- -nostdinc -I/<>/gcc/build/x86_64-linux-gnu/libgnatvsn -I/<>/gcc/build/gcc/ada/rts -I. -I/<>/gcc/src/gcc/ada -o b_gnatm.adb gnatmake.ali | /bin/bash: ../../gnatbind: No such file or directory | make[6]: *** [../gcc-interface/Makefile:2707: b_gnatm.adb] Error 127 | make[6]: Leaving directory '/<>/gcc/build/gcc/ada/tools' | make[5]: *** [Makefile:205: gnattools-native] Error 2 | make[5]: Leaving directory '/<>/gcc/build/gnattools' | make[4]: *** [Makefile:9602: all-gnattools] Error 2 | make[4]: Leaving directory '/<>/gcc/build' | make[3]: *** [Makefile:923: all] Error 2 | make[3]: Leaving directory '/<>/gcc/build' This could be a missing dependency of some sorts. Matthias usually does source-only uploads and the package builds fine on the buildds though. Santiago has been doing a non-parallel indep-only build here. Possibly the parallel build gets the dependency right by chance? Helmut
Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler
Hi, On Wed, Jan 23, 2019 at 05:52:19PM +0100, Amaury Pouly wrote: > Probably gcc-8 should be in conflict with binutils-x86-64-linux-gnu:i386 > because > of the following chain of events: > - install an unstable amd64 system > - enable multiarch i386 > - install gcc-8 > - install binutils-x86-64-linux-gnu:i386 > => This will (because of a conflict) uninstall binutils-x86-64-linux-gnu > Now the compiler is broken with this message: > /usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so: error loading plugin: > /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so: mauvaise classe ELF : > ELFCLASS64 What you describe is a real bug. When I designed the new binutils multiarch interface I failed to notice that you can load plugins into binutils. Thus we are missing an architecture constraint here. > This is because the plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so > is installed by gcc-8 (it is an amd64 executable) but is loaded by ld. Since > we can independently install the 32-bit version of the binutils, now we > have a 32-bit executable loading a 64-bit library. I am not sure what is the > proper fix but clearly it should be impossible to install the 32-bit version > of binutils with the 64-bit version of gcc-8 because of this plugin. > This probably explains bug #916603 (with gcc-6 instead of gcc-8). I vaguely agree. I had hoped that you could mix and match gcc and binutils, but apparently this is not the case. While most users of binutils do not care about binutils' actual architecture, gcc clearly does. > Note that it may be strange to install binutils-x86-64-linux-gnu:i386 but > somehow APT decided to do it on its own at some point and I did not notice > so this can happen automatically. It's not as strange as you might think. It was actually intended to work that way and I think I tested it earlier. Maybe that was before the lto plugin became mandatory. Ultimately, this means that marking binutils- M-A:foreign was wrong. It means that binutils plays the same role as ruby, perl, python and even make: you can load shared objects into it, but much of the time you don't. All of the other examples are M-A:allowed, so I guess binutils- needs to become M-A:allowed as well. Given that gcc Depends on binutils, binutils is M-A:no, and binutils Depends: binutils- without :any, the switch from M-A:foreign to M-A:allowed should fix this this bug, but at the same time it would break a fair number of use cases. We specifically have binutils-for-host to allow using foreign binutils. Likely binutils-for-host should Depends: binutils-:any then. On the flip side, that means that whenever you need plugins, you cannot use binutils-for-host. Now marking anything M-A:allowed is basically irreversible, because people are going to use :any and all those deps break when removing M-A:allowed. Therefore we should think hard about whether this is the right route. I've added debian-cross@l.d.o to Cc to elicit some feedback. Failing that, I'll prepare a patch for doing the M-A:allowed thingy. Helmut
Bug#916376: gfortran-8-* has bad provides
Hi Matthias, On Tue, Dec 18, 2018 at 02:32:16AM +0100, Matthias Klose wrote: > doesn't this approach of dropping the provides only defers the problem? You > will > see that again when cross building packages. So it looks to me that you want > to > include in the multiarch id into these provides. My approach certainly defers the problem. For a number of other tools, what you propose is what happens indeed. I considered that option, but figured that it was not worth the effort: Nobody uses the suffixed names (as nothing provides them) and once the -for-host packages are there, they can provide these packages. On the other hand, these provides are wrong and they make diagnosing installation failures unnecessarily hard. Therefore removing them looks like an incremental step to me. As you point out, readding them later will likely be needed. > Please make sure that renaming the gfortran-mod-15 provides is coordinates > with > the people caring about gfortran (Debian Science, Alistair?). I'm still hoping that there is will be no need to rename. Helmut
Bug#916376: gfortran-8-* has bad provides
Source: gcc-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affetcs -1 + src:gcc-8-cross src:gcc-8-cross-ports
gfortran-8- presently Provides: gfortran-mod-15 and given
that gfortran-8- is Multi-Arch: foreign, this is provided
for any architecture. libopenmpi-dev Depends: gfortran-8 |
gfortran-mod-15. Therefore gfortran-8- satisfies
libopenmpi-dev's dependency. That's not what we want here though. The
dependency should only be satisfied by a compiler that matches
libopenmpi-dev's architecture. Therefore these provides are bad. They
result in strange solutions which are found by dose-builddebcheck, but
are not by apt.
I propose simply removing these provides for the cross tools. The
attached patch implements that.
Helmut
diff -u gcc-8-8.2.0/debian/control.m4 gcc-8-8.2.0/debian/control.m4
--- gcc-8-8.2.0/debian/control.m4
+++ gcc-8-8.2.0/debian/control.m4
@@ -3565,7 +3565,8 @@
')dnl
Priority: optional
Depends: BASEDEP, gcc`'PV`'TS (= ${gcc:Version}), libidevdep(gfortran`'PV-dev,,=), ${dep:libcdev}, ${shlibs:Depends}, ${misc:Depends}
-Provides: fortran95-compiler, ${fortran:mod-version}
+ifdef(`TARGET',`',`Provides: fortran95-compiler, ${fortran:mod-version}
+')dnl
Suggests: ${gfortran:multilib}, gfortran`'PV-doc,
libdbgdep(gfortran`'FORTRAN_SO-dbg,),
libcoarrays-dev
@@ -3900,7 +3901,8 @@
')dnl
Priority: optional
Depends: BASEDEP, ifdef(`STANDALONEGO',`${dep:libcc1}, ',`gcc`'PV`'TS (= ${gcc:Version}), ')libidevdep(go`'GO_SO,,>=), ${dep:libcdev}, ${shlibs:Depends}, ${misc:Depends}
-Provides: go-compiler
+ifdef(`TARGET',`',`Provides: go-compiler
+')dnl
Suggests: ${go:multilib}, gccgo`'PV-doc, libdbgdep(go`'GO_SO-dbg,)
Conflicts: ${golang:Conflicts}
Breaks: libgo12`'LS (<< 8-20171209-2)
@@ -4858,7 +4860,8 @@
')dnl
Priority: optional
Depends: SOFTBASEDEP, g++`'PV`'TS (>= ${gcc:SoftVersion}), ${dep:gdccross}, ${dep:phobosdev}, ${shlibs:Depends}, ${misc:Depends}
-Provides: gdc, d-compiler, d-v2-compiler
+ifdef(`TARGET',`',`Provides: gdc, d-compiler, d-v2-compiler
+')dnl
Replaces: gdc (<< 4.4.6-5)
BUILT_USING`'dnl
Description: GNU D compiler (version 2)`'ifdef(`TARGET)',` (cross compiler for TARGET architecture)', `')
Bug#915194: valgrind log
On Mon, Dec 03, 2018 at 01:30:43AM +0800, YunQiang Su wrote:
> YunQiang Su 于2018年12月2日周日 下午11:42写道：
> >
> > Matthias Klose 于2018年12月2日周日 下午4:51写道：
> > >
> > > On 02.12.18 09:31, Aron Xu wrote:
> > > > Running with Valgrind shows some errors:
> > >
> > > that might point to the gcc-search-prefixed-as-ld patch.
>
> yes. with gcc-search-prefixed-as-ld patch removed, it works now.
The patch is necessary for making gcc-for-host happen. It is the second
attempt at solving that part of the problem and I don't particularly
like the patch (though my previous attempt broke something else).
I think there is yet another way of solving that part without patching
gcc at all: Supplying /usr/lib/gcc///{as,ld} as
symlinks pointing to the triplet-prefixed binutils should be sufficient.
Not having to add another patch should help reduce the maintenance cost.
Given that gcc-for-host is not a thing yet and that there still are
alternative approaches, I'm in favour of just reverting that patch with
no replacement now to unblock your work.
Helmut
Bug#666743: draft implementation for a Multi-Arch: foreign interface to gcc
On Sat, Apr 28, 2018 at 01:06:20PM +0200, Matthias Klose wrote:
> As addition to the feedback given on irc,
Thank you very much for spending time on this tricky feature and your
patience. I'm attaching an improved patch, but it is certainly not ready
for merging and I don't expect Matthias to look into it. This mail
merely constitutes a random snapshot of my work on the patch. Help from
others is appreciated.
> - please complete the patch to cover all frontends. while these
>might not be necessary for your bootstrap effort, I'd like to
>have all frontends be covered in an uniform way.
I've worked on this. It now covers cpp, cxx, d, fortran, gcc, go and
objc. Notably, it does not cover ada, brig or objc++. ada looks
complex. brig depends on hsail-tools, which is not Multi-Arch: foreign.
So we cannot do brig at this time. objc++ looks manageable.
> - as the first step, please don't build any -for-host and -for-build
>packages yet.
In the interest of keeping the diff manageable, this was the intention.
The addition of -for-host or -for-build packages will be covered in a
different bug report.
> - for testing:
Given that the patch is still very much incomplete, I've not performed
much testing beyond native builds and running lintian.
Helmut
diff -u gcc-8-8.2.0/debian/changelog gcc-8-8.2.0/debian/changelog
--- gcc-8-8.2.0/debian/changelog
+++ gcc-8-8.2.0/debian/changelog
@@ -1,3 +1,10 @@
+gcc-8 (8.2.0-7.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ *
+
+ -- Helmut Grohne Sat, 29 Sep 2018 13:31:54 +0200
+
gcc-8 (8.2.0-7) unstable; urgency=medium
* Update to SVN 20180917 (r264370) from the gcc-8-branch.
diff -u gcc-8-8.2.0/debian/control.m4 gcc-8-8.2.0/debian/control.m4
--- gcc-8-8.2.0/debian/control.m4
+++ gcc-8-8.2.0/debian/control.m4
@@ -35,6 +35,13 @@
'))
define(`TARGET_PACKAGE',`X-DH-Build-For-Type: target
')
+define(`_for_each',`ifelse(`$3',`',`',`pushdef(`$1',`$3')$2`'popdef(`$1')`'$0(`$1',`$2',shift(shift(shift($@')')
+define(`for_each_arch',`_for_each(`_arch',`dnl
+pushdef(`arch_deb',`patsubst(_arch,`=.*',`')')dnl
+pushdef(`arch_gnu',`patsubst(_arch,`.*=',`')')dnl
+pushdef(`arch_gnusuffix',`-patsubst(arch_gnu,`_',`-')')dnl
+$1`'popdef(`arch_gnusuffix')popdef(`arch_gnu')popdef(`arch_deb')',dnl
+patsubst(ARCH_GNUTYPE_MAP,`\s+',`,'))')
divert`'dnl
dnl --
@@ -701,21 +708,22 @@
')`'dnl x32dev
')`'dnl cdev
-ifenabled(`cdev',`
-Package: gcc`'PV`'TS
-Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
-')dnl
+ifenabled(`cdev',`dnl
+for_each_arch(`
+Package: gcc`'PV`'arch_gnusuffix
+Architecture: ifdef(`TARGET',`any',arch_deb)
+Multi-Arch: foreign
Section: devel
Priority: optional
-Depends: cpp`'PV`'TS (= ${gcc:Version}),ifenabled(`gccbase',` BASEDEP,')
+Depends: cpp`'PV`'arch_gnusuffix (= ${gcc:Version}),ifenabled(`gccbase',` BASEDEP,')
ifenabled(`gccxbase',` BASEDEP,')
${dep:libcc1},
- binutils`'TS (>= ${binutils:Version}),
+ binutils`'arch_gnusuffix (>= ${binutils:Version}),
${dep:libgccdev}, ${shlibs:Depends}, ${misc:Depends}
Recommends: ${dep:libcdev}
-Replaces: gccgo-8 (<< ${gcc:Version}), cpp`'PV`'TS (<< 7.1.1-8)
-Suggests: ${gcc:multilib}, gcc`'PV-doc (>= ${gcc:SoftVersion}),
+Replaces: gccgo-8 (<< ${gcc:Version}), cpp`'PV`'arch_gnusuffix (<< 7.1.1-8), gcc`'PV (<< 999:0TODO)
+Breaks: gcc`'PV (<< 0TODO)
+Suggests: gcc`'PV-doc (>= ${gcc:SoftVersion}),
gcc`'PV-locales (>= ${gcc:SoftVersion}),
libdbgdep(gcc`'GCC_SO-dbg,,>=,${libgcc:Version}),
libdbgdep(gomp`'GOMP_SO-dbg,),
@@ -730,15 +738,44 @@
')`'dnl
libdbgdep(mpx`'MPX_SO-dbg,),
libdbgdep(quadmath`'QMATH_SO-dbg,)
-Provides: c-compiler`'TS
+Provides: c-compiler`'arch_gnusuffix
ifdef(`TARGET',`Conflicts: gcc-multilib
')`'dnl
BUILT_USING`'dnl
-Description: GNU C compiler`'ifdef(`TARGET)',` (cross compiler for TARGET architecture)', `')
+Description: GNU C compiler for the arch_gnu architecture
+ This is the GNU C compiler for the arch_gnu architecture,
+ a fairly portable optimizing compiler for C.
+')`'dnl for_each_arch
+ifdef(`TARGET',`',`
+Package: gcc`'PV
+Architecture: any
+Section: devel
+Priority: optional
+Depends: gcc`'PV`'${target:suffix} (= ${gcc:Version}),ifenabled(`gccbase',` BASEDEP,')
+ ifenabled(`gccxbase',` BASEDEP,')
+ binutils (>= ${binutils:Version}),
+ ${misc:Depends}
+Recommends: ${dep:libcdev}
+Replaces: gccgo-8 (<< ${gcc:Version}), cpp`'PV (<< 7.1.1-8)
+Suggests: ${gcc:multilib}, gcc`'PV-doc (>= ${gcc:SoftVersion}),
+ gcc`'PV-locales (>= ${gcc:SoftVersion}),
+ libdbgdep(gcc`'GCC_SO-dbg,,>=,${libgcc:Version}),
+ libdbgdep(gomp`'GOMP_SO-dbg,),
+ libdbgdep(itm`'ITM_SO-dbg,),
+ libdbgdep(atomic`'ATOMIC_SO-dbg,),
+ libdbgdep(asan`'ASAN_SO-dbg,),
+ libdbgdep(lsan`'LSAN_SO-dbg,),
+ libdbgdep(tsan`'TSAN_SO-dbg,),
+ libdbgdep(ubsan`'UBSAN_SO-dbg,),
+ifenabled(`libvtv',`',`
+ libd
Bug#892281: gcc: make PIE opt-out rather than opt-in
Control: tags -1 + patch On Wed, Mar 07, 2018 at 07:16:26PM +0100, Helmut Grohne wrote: > Since it practically is the default "everywhere", can we move on to > enable PIE for all "new" architectures by turning the opt-in list > opt-out? While at it, can we keep this list as small as possible? At > least for musl-linux-any and x32, we know that !PIE causes more harm > than PIE. The attached patch implements opt-in. It does not change x32 to be conservative. It does change musl to keep the list short, but there is no relevant Debian musl deployment anyhow. Helmut diff -u gcc-8-8.2.0/debian/changelog gcc-8-8.2.0/debian/changelog --- gcc-8-8.2.0/debian/changelog +++ gcc-8-8.2.0/debian/changelog @@ -1,3 +1,10 @@ +gcc-8 (8.2.0-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Make PIE opt-out starting with buster. (Closes: 892281) + + -- Helmut Grohne Sat, 29 Sep 2018 09:37:18 +0200 + gcc-8 (8.2.0-7) unstable; urgency=medium * Update to SVN 20180917 (r264370) from the gcc-8-branch. diff -u gcc-8-8.2.0/debian/rules.defs gcc-8-8.2.0/debian/rules.defs --- gcc-8-8.2.0/debian/rules.defs +++ gcc-8-8.2.0/debian/rules.defs @@ -1243,7 +1243,8 @@ hurd-i386 riscv64 endif ifeq (,$(filter $(distrelease),wheezy squeeze jessie stretch)) -pie_archs += powerpc ppc64 +nopie_archs = alpha arm arm64ilp32 armeb avr32 hppa ia64 m32r m68k nios2 \ + or1k powerpcel powerpcspe s390 sh3 sh3eb sh4 sh4eb tilegx x32 endif else ifeq ($(distribution),Ubuntu) ifeq (,$(filter $(distrelease),lucid precise trusty utopic vivid wily)) @@ -1256,8 +1257,14 @@ pie_archs += armhf arm64 i386 endif endif -ifneq (,$(filter $(DEB_TARGET_ARCH),$(pie_archs))) - with_pie := yes +ifneq (,$(nopie_archs)) + ifeq (,$(filter $(DEB_TARGET_ARCH),$(nopie_archs))) +with_pie := yes + endif +else + ifneq (,$(filter $(DEB_TARGET_ARCH),$(pie_archs))) +with_pie := yes + endif endif ifeq ($(trunk_build),yes) with_pie := disabled for trunk builds
Bug#909112: isl FTCBFS: installing python3 for a foreign architecture fails postinst
Source: isl Version: 0.20-2 Tags: patch User: helm...@debian.org Usertags: rebootstrap isl fails to cross build from source, because installing its Build-Depends fails in python3.6-minimal's postinst. Actually, isl does not need the host architecture python. The build architecture python is what it needs. After fixing Build-Depends, isl cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru isl-0.20/debian/changelog isl-0.20/debian/changelog --- isl-0.20/debian/changelog 2018-08-14 12:14:35.0 +0200 +++ isl-0.20/debian/changelog 2018-09-18 17:21:59.0 +0200 @@ -1,3 +1,10 @@ +isl (0.20-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Annotate Build-Depends: python3 with :any. (Closes: #-1) + + -- Helmut Grohne Tue, 18 Sep 2018 17:21:59 +0200 + isl (0.20-2) unstable; urgency=medium * libisl-dev: Conflict with libcloog-isl-dev. Closes: #905792. diff --minimal -Nru isl-0.20/debian/control isl-0.20/debian/control --- isl-0.20/debian/control 2018-08-14 12:14:25.0 +0200 +++ isl-0.20/debian/control 2018-09-18 17:19:00.0 +0200 @@ -3,7 +3,7 @@ Maintainer: Debian GCC Maintainers Uploaders: Matthias Klose Build-Depends: debhelper (>= 9), dh-autoreconf, - libgmp-dev, python3 + libgmp-dev, python3:any Standards-Version: 4.1.5 Section: libs Homepage: http://isl.gforge.inria.fr/
Bug#804190: please support cross compiler builds without relying on binutils-multiarch
Control: reassign -1 src:gcc-8
Control: tags -1 + patch
Hi Matthias,
I've updated the patch now. It has become fairly trivial.
We added support for "X-DH-Build-For-Type: target" a while ago. That
flag alone makes dh_strip choose the right tooling.
So whenever debhelper is recent enough, we can just skip the
binutils-multiarch dependency.
On Fri, Nov 13, 2015 at 12:20:14AM +0100, Matthias Klose wrote:
> - please update the patch to apply to the current VCS
Please tell me where to find the current VCS. I've attached a patch
against the version in unstable anyhow.
> - the patch is incomplete. It still calls the binutils tools
>for the host unprefixed.
This is solved by X-DH-Build-For-Type.
> - maybe make it clear which tools are used (target_strip, host_strip
>instead of cross_strip).
No cross_strip is needed at all anymore as X-DH-Build-For-Type has taken
care of this.
> I think that the rather simplistic view of dh_strip should be addressed in
> this context too, always using the non-prefixed binutils tools. In GCC you
> don't have binary packages anymore with both host and target objects within
> the same binary package, however this is not guaranteed for other binary
> packages. So you need to find a way to strip host and target objects in the
> same binary package.
I didn't encounter a single binary package that ships both host and
target objects. Whenever they do, we can simply split the packages.
debhelper and dh_strip now support selecting host vs. target per binary
package and we're actively using that support since gcc-7.
Helmut
--- a/debian/rules.conf
+++ b/debian/rules.conf
@@ -221,7 +221,7 @@
endif
endif
ifeq ($(DEB_CROSS),yes)
- BINUTILS_BUILD_DEP = binutils$(TS)$(NT) (>= $(BINUTILSBDV)), binutils-multiarch$(NT) (>= $(BINUTILSBDV))
+ BINUTILS_BUILD_DEP = binutils$(TS)$(NT) (>= $(BINUTILSBDV)), debhelper (>= 10.10.6~) | binutils-multiarch$(NT) (>= $(BINUTILSBDV))
BINUTILSV := $(shell dpkg -l binutils$(TS) \
| awk '/^ii/{print $$3;exit}' | sed 's/-.*//')
else
Bug#905539: gcc-7 FTBFS with isl 0.20
Source: gcc-7 Version: 7.3.0-27 Severity: serious Tags: ftbfs User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I'm not sure whether you're aware already, but I felt that it was best to just document that gcc-7 fails to build against isl 0.20. I tried to check the vcs on whether this is already pending, but since alioth is offline finding the vcs is difficult. Maybe you could also update the Vcs fields. Build log symptom: | ../../src/gcc/graphite-optimize-isl.c: In function 'isl_schedule_node* get_schedule_for_node_st(isl_schedule_node*, void*)': | ../../src/gcc/graphite-optimize-isl.c:57:52: error: 'isl_space_dim' was not declared in this scope |unsigned dims = isl_space_dim (space, isl_dim_set); Helmut
Bug#904139: stockfish FTBFS on armel, mips, mipsel, m68k, powerpc, powerpcspe, sh4: undefined reference to `__atomic_store_8'
Source: stockfish Version: 9-1 Severity: serious Tags: ftbfs User: helm...@debian.org Usertags: rebootstrap stockfish fails to build from source on armel, mips, mipsel, m68k, powerpc, powerpcspe and sh4. A build log from mips ends with: | g++ -o stockfish benchmark.o bitbase.o bitboard.o endgame.o evaluate.o main.o material.o misc.o movegen.o movepick.o pawns.o position.o psqt.o search.o thread.o timeman.o tt.o uci.o uc | ioption.o syzygy/tbprobe.o -Wl,-z,relro -Wl,--no-as-needed -lpthread -g -O2 -fdebug-prefix-map=/home/helmutg/stockfish-9=. -fstack-protector-strong -Wformat -Werror=format-security -W | all -Wcast-qual -fno-exceptions -std=c++11 -pedantic -Wextra -Wshadow -DNDEBUG -O3 -DNO_PREFETCH -flto -Wl,--no-as-needed -lpthread -g -O2 -fdebug-prefix-map=/home/helmutg/stockfish- | 9=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wcast-qual -fno-exceptions -std=c++11 -pedantic -Wextra -Wshadow -DNDEBUG -O3 -DNO_PREFETCH -flto -Wall -Wcast-qua | l -fno-exceptions -std=c++11 -pedantic -Wextra -Wshadow -DNDEBUG -O3 -DNO_PREFETCH -flto -lgcov -Wl,--no-as-needed -lpthread -g -O2 -fdebug-prefix-map=/home/helmutg/stockfish-9=. -fst | ack-protector-strong -Wformat -Werror=format-security -Wall -Wcast-qual -fno-exceptions -std=c++11 -pedantic -Wextra -Wshadow -DNDEBUG -O3 -DNO_PREFETCH -flto -Wall -Wcast-qual -fno-e | xceptions -std=c++11 -pedantic -Wextra -Wshadow -DNDEBUG -O3 -DNO_PREFETCH -flto -Wall -Wcast-qual -fno-exceptions -std=c++11 -fprofile-generate -pedantic -Wextra -Wshadow -DNDEBUG -O | 3 -DNO_PREFETCH -flto | /usr/bin/ld: /usr/bin/ld: DWARF error: could not find abbrev number 127 | /tmp/ccNba2xu.ltrans0.ltrans.o: in function `TimeManagement::elapsed() const [clone .isra.66] [clone .constprop.25]': | /usr/include/c++/8/bits/basic_string.tcc:(.text+0xcd0c): undefined reference to `__atomic_load_8' | /usr/bin/ld: /usr/include/c++/8/bits/basic_string.tcc:(.text+0xcd20): undefined reference to `__atomic_load_8' | /usr/bin/ld: /tmp/ccNba2xu.ltrans0.ltrans.o: in function `Value (anonymous namespace)::search<((anonymous namespace)::NodeType)1>(Position&, Search::Stack*, Value, Value, Depth, bool, bool) [clone .constprop.7]': | /usr/include/c++/8/bits/basic_string.tcc:(.text+0x13ad0): undefined reference to `__atomic_fetch_add_8' | /usr/bin/ld: /usr/include/c++/8/bits/basic_string.tcc:(.text+0x13ae4): undefined reference to `__atomic_fetch_add_8' | /usr/bin/ld: /usr/bin/ld: DWARF error: offset (262144) greater than or equal to .debug_str size (29238) | /usr/bin/ld: DWARF error: mangled line number section (bad file number) | /usr/bin/ld: DWARF error: could not find abbrev number 8986 | /tmp/ccNba2xu.ltrans3.ltrans.o: in function `ThreadPool::start_thinking(Position&, std::unique_ptr >, std::default_delete > > >&, Search::LimitsType const&, bool)': | tt.cpp:(.text+0xb500): undefined reference to `__atomic_store_8' | /usr/bin/ld: tt.cpp:(.text+0xb51c): undefined reference to `__atomic_store_8' | /usr/bin/ld: tt.cpp:(.text+0xb4dc): undefined reference to `__atomic_store_8' | /usr/bin/ld: tt.cpp:(.text+0xb518): undefined reference to `__atomic_store_8' | /usr/bin/ld: /tmp/ccNba2xu.ltrans3.ltrans.o: in function `UCI::loop(int, char**)': | tt.cpp:(.text+0xff1c): undefined reference to `__atomic_load_8' | /usr/bin/ld: tt.cpp:(.text+0xff30): undefined reference to `__atomic_load_8' | /usr/bin/ld: /usr/bin/ld: DWARF error: invalid abstract instance DIE ref | /tmp/ccNba2xu.ltrans4.ltrans.o: in function `Value (anonymous namespace)::search<((anonymous namespace)::NodeType)0>(Position&, Search::Stack*, Value, Value, Depth, bool, bool) [clone .lto_priv.214]': | search.cpp:(.text+0xf2b4): undefined reference to `__atomic_fetch_add_8' | /usr/bin/ld: search.cpp:(.text+0xf2c8): undefined reference to `__atomic_fetch_add_8' | /usr/bin/ld: /usr/bin/ld: DWARF error: invalid abstract instance DIE ref | /tmp/ccNba2xu.ltrans5.ltrans.o: in function `UCI::pv[abi:cxx11](Position const&, Depth, Value, Value)': | position.cpp:(.text+0x4b00): undefined reference to `__atomic_load_8' | /usr/bin/ld: position.cpp:(.text+0x4b14): undefined reference to `__atomic_load_8' | /usr/bin/ld: position.cpp:(.text+0x4b70): undefined reference to `__atomic_load_8' | /usr/bin/ld: position.cpp:(.text+0x4b84): undefined reference to `__atomic_load_8' | /usr/bin/ld: /tmp/ccNba2xu.ltrans5.ltrans.o: in function `MainThread::check_time()': | position.cpp:(.text+0x63d8): undefined reference to `__atomic_load_8' | /usr/bin/ld: /tmp/ccNba2xu.ltrans5.ltrans.o:position.cpp:(.text+0x63ec): more undefined references to `__atomic_load_8' follow | /usr/bin/ld: /tmp/ccNba2xu.ltrans5.ltrans.o: in function `Position::do_move(Move, StateInfo&, bool)': | position.cpp:(.text+0x7c2c): undefined reference to `__atomic_fetch_add_8' | /usr/bin/ld: position.cpp:(.text+0x7c3c): undefined reference to `__atomic_fetch_add_8' | /usr/bin/ld: /tmp/ccNba2xu.ltrans5.ltrans.o: in function `MainThread::search()': |
Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B
Hi Jakub,
On Thu, Apr 19, 2018 at 12:31:03AM +0200, Jakub Wilk wrote:
> GCC no longer looks for "as" in the directory specified by the -B option:
Yes, I asked Matthias for passing --with-as to gcc.
> This breaks afl-gcc (part of the afl package), which uses the -B option to
> talk GCC into using a hacked version of the assembler.
>
> I guess this is fallout from fixing #895251.
I am sorry for having broken afl-gcc along the way and imposing the
work of discovering why on you.
> Previously it worked like this:
>
> $ gcc --version | head -n1
> gcc (Debian 7.3.0-15) 7.3.0
>
> $ strace -f -o '| grep -w as' gcc -B/foo/bar/ -c -x c /dev/null
> 3770 stat("/foo/bar/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT
> (No such file or directory)
> 3770 stat("/foo/bar/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT (No
> such file or directory)
> 3770 stat("/foo/bar/as", 0x7ffd82351450) = -1 ENOENT (No such file or
> directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1
> ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1
> ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT
> (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1
> ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT
> (No such file or directory)
> 3770
> stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as",
> 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770
> stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/as",
> 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770
> stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/as",
> 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3773 execve("/usr/local/bin/as", ["as", "--64", "-o", "null.o",
> "/tmp/ccFhN057.s"], 0xbe46d0 /* 24 vars */) = -1 ENOENT (No such file or
> directory)
> 3773 execve("/usr/bin/as", ["as", "--64", "-o", "null.o",
> "/tmp/ccFhN057.s"], 0xbe46d0 /* 24 vars */
>
> As you can see, GCC was already looking for "as" in a triplet-specific
> directory. So perhaphs gcc-7 should ship an appropriate symlink in
> /usr/lib/gcc//7/, instead of hardcoding path to "as" at configure
> time?
Your suggestion makes a lot of sense. The devil is in the detail though:
* Does it work the same way for ld?
* Do cross toolchains also need such a symlink?
* If yes, where to place it? (They use a different directory layout.)
* Which make variable contains the correct path?
Plan:
* I think it is reasonable to simply revert #895251 for the time being.
That should fix this bug.
* I'll look into the details and will propose an improved patch.
Helmut
Bug#666743: draft implementation for a Multi-Arch: foreign interface to gcc
Control: reopen -1
Control: reassign -1 src:gcc-8
Hi Matthias,
you requested that I send my unfinished work and here it goes. I've seen
that you have quickly applied my previous patches towards this matter
and would like to thank you. The attached patch was last tested on
8-20180402-1. I performed the following test methods thus far:
* native build (reduced using nolang=...)
* lintian
* piuparts
* looking at package contents
* manually installing and testing the resulting packages (thus
discovering #891289)
Caveats:
* The patch still contains temporary Breaks/Replaces versions. You'll
find them by searching for /0TODO/ in debian/control.m4. These need
to be updated before uploading (as we are moving files to new
packages).
* You'll go through NEW of course.
* I did not perform cross builds or cross compiler builds.
* I did not perform non-dfsg builds.
* I did not perform gcc-snapshot builds.
I had to make a number of bike coloring decision during the
implementation. If you want something different, I'm happy to change
that and will try to update the patch in a timely manner.
* "arch_gnutype_map" gets passed to control.m4 as "ARCH_GNUTYPE_MAP".
* The target suffix of the new packages is passed as a substvar called
"target:suffix".
* The make variables for these packages are called "p_${tool}n" and
"d_${tool}n".
* The new targets are called "$(binary_stamp)-$(tool)-nat".
I would like to thank James Clarke his advice during the planning stage
and for reviewing an earlier version of this patch.
I'd also be interested in learning which test build configurations are
particularly relevant to you.
I'v Cced d-cross@l.d.o to have more eyeballs on this difficult piece of
code.
Helmut
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -35,6 +35,13 @@
'))
define(`TARGET_PACKAGE',`X-DH-Build-For-Type: target
')
+define(`_for_each',`ifelse(`$3',`',`',`pushdef(`$1',`$3')$2`'popdef(`$1')`'$0(`$1',`$2',shift(shift(shift($@')')
+define(`for_each_arch',`_for_each(`_arch',`dnl
+pushdef(`arch_deb',`patsubst(_arch,`=.*',`')')dnl
+pushdef(`arch_gnu',`patsubst(_arch,`.*=',`')')dnl
+pushdef(`arch_gnusuffix',`-patsubst(arch_gnu,`_',`-')')dnl
+$1`'popdef(`arch_gnusuffix')popdef(`arch_gnu')popdef(`arch_deb')',dnl
+patsubst(ARCH_GNUTYPE_MAP,`\s+',`,'))')
divert`'dnl
dnl --
@@ -700,21 +707,22 @@
')`'dnl x32dev
')`'dnl cdev
-ifenabled(`cdev',`
-Package: gcc`'PV`'TS
-Architecture: any
-ifdef(`TARGET',`Multi-Arch: foreign
-')dnl
+ifenabled(`cdev',`dnl
+for_each_arch(`
+Package: gcc`'PV`'arch_gnusuffix
+Architecture: ifdef(`TARGET',`any',arch_deb)
+Multi-Arch: foreign
Section: devel
Priority: optional
-Depends: cpp`'PV`'TS (= ${gcc:Version}),ifenabled(`gccbase',` BASEDEP,')
+Depends: cpp`'PV`'arch_gnusuffix (= ${gcc:Version}),ifenabled(`gccbase',` BASEDEP,')
ifenabled(`gccxbase',` BASEDEP,')
${dep:libcc1},
- binutils`'TS (>= ${binutils:Version}),
+ binutils`'arch_gnusuffix (>= ${binutils:Version}),
${dep:libgccdev}, ${shlibs:Depends}, ${misc:Depends}
Recommends: ${dep:libcdev}
-Replaces: gccgo-8 (<< ${gcc:Version}), cpp`'PV`'TS (<< 7.1.1-8)
-Suggests: ${gcc:multilib}, gcc`'PV-doc (>= ${gcc:SoftVersion}),
+Replaces: gccgo-8 (<< ${gcc:Version}), cpp`'PV`'arch_gnusuffix (<< 7.1.1-8), gcc`'PV (<< 999:0TODO)
+Breaks: cpp`'PV (<< 0TODO)
+Suggests: gcc`'PV-doc (>= ${gcc:SoftVersion}),
gcc`'PV-locales (>= ${gcc:SoftVersion}),
libdbgdep(gcc`'GCC_SO-dbg,,>=,${libgcc:Version}),
libdbgdep(gomp`'GOMP_SO-dbg,),
@@ -729,15 +737,44 @@
')`'dnl
libdbgdep(mpx`'MPX_SO-dbg,),
libdbgdep(quadmath`'QMATH_SO-dbg,)
-Provides: c-compiler`'TS
+Provides: c-compiler`'arch_gnusuffix
ifdef(`TARGET',`Conflicts: gcc-multilib
')`'dnl
BUILT_USING`'dnl
-Description: GNU C compiler`'ifdef(`TARGET)',` (cross compiler for TARGET architecture)', `')
+Description: GNU C compiler for the arch_gnu architecture
+ This is the GNU C compiler for the arch_gnu architecture, a fairly portable
+ optimizing compiler for C.
+')`'dnl for_each_arch
+ifdef(`TARGET',`',`
+Package: gcc`'PV
+Architecture: any
+Section: devel
+Priority: optional
+Depends: gcc`'PV`'${target:suffix} (= ${gcc:Version}),ifenabled(`gccbase',` BASEDEP,')
+ ifenabled(`gccxbase',` BASEDEP,')
+ binutils (>= ${binutils:Version}),
+ ${misc:Depends}
+Recommends: ${dep:libcdev}
+Replaces: gccgo-8 (<< ${gcc:Version}), cpp`'PV (<< 7.1.1-8)
+Suggests: ${gcc:multilib}, gcc`'PV-doc (>= ${gcc:SoftVersion}),
+ gcc`'PV-locales (>= ${gcc:SoftVersion}),
+ libdbgdep(gcc`'GCC_SO-dbg,,>=,${libgcc:Version}),
+ libdbgdep(gomp`'GOMP_SO-dbg,),
+ libdbgdep(itm`'ITM_SO-dbg,),
+ libdbgdep(atomic`'ATOMIC_SO-dbg,),
+ libdbgdep(asan`'ASAN_SO-dbg,),
+ libdbgdep(lsan`'LSAN_SO-dbg,),
+ libdbgdep(tsan`'TSAN_SO-dbg,),
+ libdbgdep(ubsan`'UBSAN_SO-dbg,),
+ifenabled(`libvtv',`',`
+ libdbgdep(vtv`'VTV_SO-dbg,),
+')`'dnl
+ libdbgdep(mpx`'MPX_SO-dbg,),
+ libdbgdep(quadmath`'QMATH_SO-dbg,)
+Provides:
Bug#895251: gcc-8: use triplet-prefixed binutils
Source: gcc-8 Version: 8-20180218-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Control: block 666743 by -1 While working on coinstallable toolchains I ran into another problem. When we want to install two native toolchains for different architectures, we also want two native binutils for these architectures. Thus /usr/bin/as is ambiguous and must not be used. Thus a triplet-prefixed compiler must not use plain as or plain ld, but that's what happens when you configure gcc for a native build. The attached patch adds the --with-as and --with-ld options pointing to the triplet-prefixed versions of these tools such that we can later switch the binutils dependency to binutils-$targettriplet. I hope I found the right place to insert these options. Helmut --- a/debian/rules2 +++ b/debian/rules2 @@ -184,7 +184,9 @@ CONFARGS += \ --enable-languages=$(subst $(SPACE),$(COMMA),$(enabled_languages)) \ --prefix=/$(PF) \ - --with-gcc-major-version-only + --with-gcc-major-version-only \ + --with-as=/usr/bin/$(DEB_TARGET_GNU_TYPE)-as \ + --with-ld=/usr/bin/$(DEB_TARGET_GNU_TYPE)-ld ifeq ($(versioned_packages),yes) CONFARGS += --program-suffix=-$(BASE_VERSION)
Bug#893493: gcc-8: simplify arch_gnutype_map and make it more consistent
Source: gcc-8 Version: 8-20180218-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Control: block 666743 by -1 Hi Matthias, this is my second patch towards gcc-for-host. It reworks the debian/rules.conf variable arch_gnutype_map. The first major change is that it is now being generated from $(any_archs). This change is intended to reduce the maintenance cost, because it will now be automatically consistent with $(any_archs). The next change is that any_archs and arch_gnutype_map always contain the target architecture. This is automatically true for release and ports architectures, but for new architectures it might not be. When using such an architecture, one may have to regenerate debian/control then. Finally, this patch fixes dependencies on architectures whose gnu triplet contains underscores (i.e. amd64). After performing this change, we can pass arch_gnutype_map into debian/control.m4 and generate all those $tool-$archsuffix:$arch packages. This is quite similar to the p_nat package in binutils. Updating of debian/control.m4 and introducing those extra packages is subject of a later patch. I would like to thank James Clarke for his help in figuring out the right approach and his review of this patch. What needs to be done before you can apply this patch? Do you need specific test builds? Helmut --- a/debian/rules.conf +++ b/debian/rules.conf @@ -445,37 +445,13 @@ ifeq (yes,$(MIPS_R6_ENABLED)) any_archs += mipsn32el mipsr6 mipsr6el mips64r6 mips64r6el mipsn32r6 mipsn32r6el endif -arch_gnutype_map = \ - alpha=alpha-linux-gnu \ - amd64=x86-64-linux-gnu \ - armel=arm-linux-gnueabi \ - armhf=arm-linux-gnueabihf \ - arm64=aarch64-linux-gnu \ - i386=i686-linux-gnu \ - mips=mips-linux-gnu \ - mipsel=mipsel-linux-gnu \ - mipsn32=mips64-linux-gnuabin32 \ - mipsn32el=mips64el-linux-gnuabin32 \ - mips64=mips64-linux-gnuabi64 \ - mips64el=mips64el-linux-gnuabi64 \ - mipsr6=mipsisa32r6-linux-gnu \ - mipsr6el=mipsisa32r6el-linux-gnu \ - mipsn32r6=mipsisa64r6-linux-gnuabin32 \ - mipsn32r6el=mipsisa64r6el-linux-gnuabin32 \ - mips64r6=mipsisa64r6-linux-gnuabi64 \ - mips64r6el=mipsisa64r6el-linux-gnuabi64 \ - powerpc=powerpc-linux-gnu \ - powerpcspe=powerpc-linux-gnuspe \ - ppc64=powerpc64-linux-gnu \ - ppc64el=powerpc64le-linux-gnu \ - m68k=m68k-linux-gnu \ - sh4=sh4-linux-gnu \ - sparc64=sparc64-linux-gnu \ - s390x=s390x-linux-gnu \ - x32=x86-64-linux-gnux32 +ifeq ($(filter $(DEB_HOST_ARCH),$(any_archs)),) +any_archs += $(DEB_HOST_ARCH) +endif -_element = $(filter $1=%,$(arch_gnutype_map)) +arch_gnutype_map := $(foreach a,$(any_archs),$(a)=$(shell CC=true dpkg-architecture -f -a$(a) -qDEB_HOST_GNU_TYPE)) _gnu_type = $(subst $1=,,$(filter $1=%,$(arch_gnutype_map))) +_gnu_suffix = -$(subst _,-,$(call _gnu_type,$1)) ifneq (,$(filter $(distrelease),lenny etch squeeze wheezy wheezy dapper hardy jaunty karmic lucid maverick natty oneiric precise quantal raring saucy trusty utopic vivid)) DEBHELPER_BUILD_DEP = debhelper (>= 9), @@ -486,16 +462,16 @@ DEBHELPER_BUILD_DEP = debhelper (>= 9.20141010), TARGET_TOOL_BUILD_DEP = \ $(foreach a, $(any_archs), \ - g++-$(BASE_VERSION)-$(call _gnu_type,$(a)) [$(a)] , \ + g++-$(BASE_VERSION)$(call _gnu_suffix,$(a)) [$(a)] , \ $(if $(filter $(a), avr),, \ - gobjc-$(BASE_VERSION)-$(call _gnu_type,$(a)) [$(a)] ,) \ - gfortran-$(BASE_VERSION)-$(call _gnu_type,$(a)) [$(a)] , \ + gobjc-$(BASE_VERSION)$(call _gnu_suffix,$(a)) [$(a)] ,) \ + gfortran-$(BASE_VERSION)$(call _gnu_suffix,$(a)) [$(a)] , \ $(if $(filter $(a), s390 sh4),, \ - gdc-$(BASE_VERSION)-$(call _gnu_type,$(a)) [$(a)] ,) \ + gdc-$(BASE_VERSION)$(call _gnu_suffix,$(a)) [$(a)] ,) \ $(if $(filter $(a), hppa m68k sh4),, \ - gccgo-$(BASE_VERSION)-$(call _gnu_type,$(a)) [$(a)] ,) \ + gccgo-$(BASE_VERSION)$(call _gnu_suffix,$(a)) [$(a)] ,) \ $(if $(filter $(a), m68k),, \ - gnat-$(BASE_VERSION)-$(call _gnu_type,$(a)) [$(a)] ,) \ + gnat-$(BASE_VERSION)$(call _gnu_suffix,$(a)) [$(a)] ,) \ ) pf_cross = $(SPACE) pf_ncross = $(SPACE) @@ -572,6 +548,7 @@ SOURCE_BUILD_DEP := gcc-$(BASE_VERSION)-source (>= $(GCC_SOURCE_VERSION)), gcc-$(BASE_VERSION)-source (<< $(NEXT_GCC_SOURCE_VERSION)), endif GNAT_BUILD_DEP := + arch_gnutype_map = $(DEB_TARGET_ARCH)=$(TARGET_ALIAS) endif # cross compiler BASE_BREAKS := gcc-4.4-base (<< 4.4.7), gcc-4.7-base (<< 4.7.3), gcj-4.4-base (<< 4.4.6-9~), gnat-4.4-base (<< 4.4.6-3~), gcj-4.6-base (<< 4.6.1-4~), gnat-4.6 (<< 4.6.1-5~)
Bug#892281: gcc: make PIE opt-out rather than opt-in
Source: gcc-8 Version: 8-20180218-1 Severity: wishlist We have long transitioned to PIE by default on all release architectures now. Still each gcc-V package tracks the architectures that enable PIE by default in an opt-in list (pie_archs). Since it is the default, PIE is much better supported than !PIE now. For instance, musl-linux-mips fails building dash, because ld segfaults. Once enabling PIE for musl, it proceeds. Similarly, x32 fails linking systemd and it obviously is connected to !PIE: ld: /tmp/cc9ezYWe.ltrans0.ltrans.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC Very likely, the riscv64 people want to enable PIE by default as well. Since it practically is the default "everywhere", can we move on to enable PIE for all "new" architectures by turning the opt-in list opt-out? While at it, can we keep this list as small as possible? At least for musl-linux-any and x32, we know that !PIE causes more harm than PIE. I've Cced this to d-devel to have people object, but I think the case is pretty clear at this point, because opt-out will reduce the maintenance cost. Helmut
Bug#891289: gcc-8: produces broken Build-Depends with nolang=biarch
Source: gcc-8 Version: 8-20180218-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Control: block 666743 by -1 While working on coinstallable toolchains, I deactivated biarch to speed up initial test builds and discovered that doing so produces broken Build-Depends. debian/control.m4 lists GCC_MULTILIB_BUILD_DEP on a single line and when nolang contains biarch, GCC_MULTILIB_BUILD_DEP happens to become empty. Thus Build-Depends contains a completely empty line and various tools don't like that at all. Thus I propose merging the line with the previous line, which is guarantueed to be non-empty. Please consider applying the attached patch. Helmut --- a/debian/control.m4 +++ b/debian/control.m4 @@ -71,8 +71,7 @@ zlib1g-dev, SDT_BUILD_DEP bison (>= 1:2.3), flex, coreutils (>= 2.26) | realpath (>= 1.9.12), lsb-release, quilt ',`dnl native -Build-Depends: DEBHELPER_BUILD_DEP DPKG_BUILD_DEP - GCC_MULTILIB_BUILD_DEP +Build-Depends: DEBHELPER_BUILD_DEP DPKG_BUILD_DEP GCC_MULTILIB_BUILD_DEP LIBC_BUILD_DEP, LIBC_BIARCH_BUILD_DEP LIBC_DBG_DEP kfreebsd-kernel-headers (>= 0.84) [kfreebsd-any], linux-libc-dev [m68k], AUTO_BUILD_DEP BASE_BUILD_DEP
Bug#879054: gcc-8 DEB_STAGE=rtlibs FTBFS: dh_installdirs: All requested packages have been excluded (e.g. via a Build-Profile).
Control: tags -1 + patch On Wed, Nov 29, 2017 at 02:33:53AM +0100, Matthias Klose wrote: > as discussed on irc, the alternative solution should be preferred. Ah, right. Thank you for the reminder. In the mean time, I tried to agree on a better header name for "X-DH-Build-For-Type: target" with Guillem and Niels, but we ultimately failed. Thus we will end up using the debhelper extension name and do without support from dpkg for now. Doing without dpkg means that dh_gencontrol does not fully honour this header and we'll have to change DEB_HOST_ARCH and friends before running it. Luckily, gcc already does this using cross_gencontrol. So I've split up this patch into four patches, because they kinda solve four different subproblems. I hope this makes reviewing them easier. #1 gcc-dhp-flags.patch This patch is only relevant to DEB_STAGE=rtlibs. While performing a DEB_STAGE=rtlibs build, we are in the strange situation that all binary packages are considered architecture independent and files like "debian/arch_binaries" and "debian/arch_binaries.all" and up being completely empty. The foreach loops generating the -p flags for debhelper will thus be empty and no -p flag will be generated at all. Rather that processing no packages, this will make the various dh_* tools process all packages. This is a bug even before debhelper became strict, but now it became fatal. #2 gcc-target-vars.patch The gcc packaging has a set of make variables DEB_TARGET_* that pretty closely mimic the dpkg-architecture variables. We need to export these as debhelper is going to use them. Furthermore, dpkg-architecture gained some new variables and those should be added here. #3 gcc-target-package.patch This patch simply adds a layer of indirection. It defines a m4 macro for the new header in control.m4. This macro makes it easy to remove the header if it turns out to be problematic. For instance, it could be made empty if the release we are building for is very old or we are not performing a cross compiler build. It also makes the next "patch" easier. #4 Adding the headers I didn't implement this change as a patch, but as a sed expression: sed -i -e '/^Package: .*`'"'"'LS$/aTARGET_PACKAGE`'"'dnl" debian/control.m4 What it does is simple enough: It looks for every package that ends in "LS" and appends the header to that package. This is the suffix that turns architecture dependent packages into -$arch-cross packages for cross compilers (other than DEB_STAGE=rtlibs). This $arch is the target architecture, so this LS suffix precisely identifies the packages that need to be enabled. I've tested cross compiler builds for gcc-7 and gcc-8 for a fair number of targets now. None of the aspects changed touch native builds in any significant way. Thus I think this patch is pretty safe. In a distant future, this change will allow us to remove a lot of magic like cross_shlibdeps, cross_makeshlibs and cross_clean as this tagging will have turned into a tagging that is performed in debian/control instead. Helmut --- a/debian/rules2 +++ b/debian/rules2 @@ -2396,10 +2396,12 @@ cat debian/arch_binaries debian/arch_binaries.epoch > debian/arch_binaries.all binary-arch: debian/arch_binaries.all + test ! -s debian/arch_binaries.all || \ dh_compress $(foreach p,$(shell echo `cat debian/arch_binaries.all`),-p$(p)) \ -X.log.xz -X.sum.xz -X.c -X.txt -X.tag -X.map -XREADME.Bugs ifeq ($(i586_symlinks),yes) cd debian; \ + test ! -s arch_binaries || \ for x in $$(find `cat arch_binaries` -type l -name 'i686-*'); do \ link=$$(echo $$x | sed 's/i686-/i586-/'); \ tgt=$$(basename $$x); \ @@ -2407,7 +2409,9 @@ rm -f $$link; cp -a $$x $$link; \ done endif + test ! -s debian/arch_binaries.all || \ dh_fixperms $(foreach p,$(shell echo `cat debian/arch_binaries.all`),-p$(p)) + test ! -s debian/arch_binaries || \ dh_gencontrol $(foreach p,$(shell echo `cat debian/arch_binaries`),-p$(p)) \ -- -v$(DEB_VERSION) $(common_substvars) @set -e; \ @@ -2416,8 +2420,11 @@ echo dh_gencontrol $$pkgs -- -v$(DEB_EVERSION) $(common_substvars); \ dh_gencontrol $$pkgs -- -v$(DEB_EVERSION) $(common_substvars); \ fi + test ! -s debian/arch_binaries.all || \ dh_installdeb $(foreach p,$(shell echo `cat debian/arch_binaries.all`),-p$(p)) + test ! -s debian/arch_binaries.all || \ dh_md5sums $(foreach p,$(shell echo `cat debian/arch_binaries.all`),-p$(p)) + test ! -s debian/arch_binaries.all || \ dh_builddeb $(foreach p,$(shell echo `cat debian/arch_binaries.all`),-p$(p)) ifeq ($(with_check),yes) @echo Done --- a/debian/rules.defs +++ b/debian/rules.defs @@ -161,6 +161,11 @@ DEB_TARGET_GNU_TYPE := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE) DEB_TARGET_GNU_SYSTEM := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM) DEB_TARGET_MULTIARCH := $(call vafilt,$(TARGET_VARS),DEB_HOST_MULTIARCH) +DEB_TARGET_ARCH_ABI := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_ABI) +DEB_TARGET_ARCH_BITS := $(call
Bug#879054: gcc-8 DEB_STAGE=rtlibs FTBFS: dh_installdirs: All requested packages have been excluded (e.g. via a Build-Profile).
Source: gcc-8,gcc-7 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, since debhelper 10.9.1, more specifically https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=93d8fdfc5dfc994af53fc6fed7f36f271b3abee5 the DEB_STAGE=rtlibs build of gcc fails. Such builds use an environment where DEB_BUILD_ARCH=DEB_HOST_ARCH=DEB_TARGET_ARCH, but internally set a different TARGET and try to produce binaries for that TARGET. When various dh_commands are instructed to operate on such packages, they now figure that they are not enabled for DEB_HOST_ARCH and thus skip them: | dh_installdirs -plibgcc1 usr/share/doc/libgcc1 /lib/x86_64-linux-gnux32 | dh_installdirs: All requested packages have been excluded (e.g. via a Build-Profile). Turning some helpers into noops quickly makes the build fail. I think that the cure is to call those helpers in an environment where DEB_HOST_ARCH is set to the TARGET. The attached patch thus introduces a $(for_target) prefix for affected commands and identifies which commands need the prefix. After applying it DEB_STAGE=rtlibs does build. Of course the other question is: What does the patch break? Whenever DEB_HOST_ARCH is equal to the TARGET, the prefix does not actually change anything, so native builds and cross builds are completely unaffected. We only need to look at cross compiler builds (such as DEB_STAGE=rtlibs, but also other stages). With the exception of DEB_STAGE=rtlibs, the affected packages become Architecture: all (in the typical dpkg-cross suffixed notation). Thus the change in DEB_HOST_ARCH is mostly irrelevant there as well (and I did perform the full 4-stage cross compiler bootstrap with the patch). For these reasons, I believe that the attached patch has a low risk of introducing regressions. I do note that Niels Thykier has been working on an alternative solution involving support from debhelper: https://anonscm.debian.org/git/debhelper/debhelper.git/log/?h=dh-cross-target That branch enables tagging binary packages in debian/control to use DEB_TARGET_ARCH whenever debhelper normally thinks DEB_HOST_ARCH. Using this debhelper branch would allow tagging binary packages rather than dh_commands, which generally means less tagging and thus a smaller risk of mistakes. The approach would also allow building updates packages on jessie and stretch, because their debhelper lacks ignores the new header and lacks the breaking commit above. Please tell if you prefer that approach. Helmut --- a/debian/rules.d/binary-fortran.mk +++ b/debian/rules.d/binary-fortran.mk @@ -86,8 +86,8 @@ mv $(install_stamp) $(install_stamp)-tmp rm -rf $(d_l) $(d_d) - dh_installdirs -p$(p_l) $(usr_lib$(2)) - $(dh_compat2) dh_movefiles -p$(p_l) $(usr_lib$(2))/libgfortran.so.* + $(for_target) dh_installdirs -p$(p_l) $(usr_lib$(2)) + $(for_target) $(dh_compat2) dh_movefiles -p$(p_l) $(usr_lib$(2))/libgfortran.so.* debian/dh_doclink -p$(p_l) $(p_lbase) debian/dh_doclink -p$(p_d) $(p_lbase) @@ -97,7 +97,7 @@ cp debian/$(p_l).overrides debian/$(p_l)/usr/share/lintian/overrides/$(p_l); \ fi - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(for_target) dh_strip -p$(p_l) --dbg-package=$(p_d) ln -sf libgfortran.symbols debian/$(p_l).symbols $(cross_makeshlibs) dh_makeshlibs -p$(p_l) $(call cross_mangle_shlibs,$(p_l)) @@ -130,7 +130,7 @@ debian/dh_doclink -p$(p_l) $(p_lbase) debian/dh_rmemptydirs -p$(p_l) - dh_strip -p$(p_l) + $(for_target) dh_strip -p$(p_l) $(cross_shlibdeps) dh_shlibdeps -p$(p_l) $(call cross_mangle_substvars,$(p_l)) echo $(p_l) >> debian/$(lib_binaries) --- a/debian/rules.d/binary-libatomic.mk +++ b/debian/rules.d/binary-libatomic.mk @@ -30,7 +30,7 @@ debian/dh_doclink -p$(p_l) $(p_lbase) debian/dh_doclink -p$(p_d) $(p_lbase) - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(for_target) dh_strip -p$(p_l) --dbg-package=$(p_d) ln -sf libatomic.symbols debian/$(p_l).symbols $(cross_makeshlibs) dh_makeshlibs -p$(p_l) $(call cross_mangle_shlibs,$(p_l)) --- a/debian/rules.d/binary-libgcc.mk +++ b/debian/rules.d/binary-libgcc.mk @@ -161,7 +161,7 @@ debian/dh_doclink -p$(2) $(p_lbase) debian/dh_rmemptydirs -p$(2) - dh_strip -p$(2) + $(for_target) dh_strip -p$(2) $(cross_shlibdeps) dh_shlibdeps -p$(2) $(call cross_mangle_substvars,$(2)) echo $(2) >> debian/$(lib_binaries) @@ -281,7 +281,7 @@ rm -rf $(d_l) $(d_d) - dh_installdirs -p$(p_l) \ + $(for_target) dh_installdirs -p$(p_l) \ $(docdir)/$(p_l) \ $(libgcc_dir$(2)) @@ -289,7 +289,7 @@ debian/dh_doclink -p$(p_d) $(if $(3),$(3),$(p_lbase)) debian/dh_rmemptydirs -p$(p_l) debian/dh_rmemptydirs -p$(p_d) - dh_strip -p$(p_l) --dbg-package=$(p_d) + $(for_target) dh_strip -p$(p_l) --dbg-package=$(p_d) # see Debian #533843 for the __aeabi symbol handling; this construct is # just to include the symbols for dpkg versions older than 1.15.3 which --- a/debian/rules.d/binary-libgomp.mk +++ b/debian/rules.d/binary-libgomp.mk @@ -24,13 +24,13 @@ mv
Bug#877589: gcc-7: DEB_STAGE=rtlibs fails to build with debhelper 10.9 due to strictness of -p and -N
Source: gcc-7 User: helm...@debian.org Usertags: rebootstrap Control: block 795432 by -1 Hi Matthias, I discovered another debhelper 10.9 regression in gcc-7. In debian/rules2, a dh_prep is passed -N$(p_hppa64) and that package is not listed in debian/control while building DEB_STAGE=rtlibs. I'm not sure whether that -N flag still needed for normal builds. If it isn't, you can remove it: sed -i -e 's/ -N$(p_hppa64)//' debian/rules2 If it is still useful, it needs to be made optional: sed -i -e 's/-N$(p_hppa64)/$(if $(filter rtlibs,$(DEB_STAGE)),,&)/' debian/rules2 Helmut
Bug#876246: gcc-7 fails to build fortran cross compiler since debhelper became strict about -p
Source: gcc-7 Tags: patch User: helm...@debian.org Usertags: rebootstrap Control: block 795432 by -1 Hi Matthias, debhelper 10.9 fixed #795432 and that makes building a fortran cross compiler fail. debian/rules.d/binary-fortran.mk says: dh_installdirs -p$(1) ... The argument is the plain package name without $(cross_lib_arch), but it needs to pass the transformed package name $(p_l) here. The following command fixes that: sed -i -e 's/ -p\$(1) / -p$(p_l) /' debian/rules.d/binary-fortran.mk It seems to be isolated to just this one occurence. I didn't find any others and after this fix, I can build fortran cross compilers again. Helmut
Bug#861588: gcc-7: update gcc-multiarch.diff for non-glibc architectures (musl, uclibc)
Source: gcc-7
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
The multiarch stuff in gcc is still not entirely upstream and we are
carrying part of it in debian/patches/gcc-multiarch.diff. Notably
missing there is support for non-glibc architectures. Would it be
reasonable to add the relevant snippets for that support there? I am
attaching a diff to gcc-multiarch.diff that makes musl and uclibc work.
It would be nice if you could apply it.
Thank you
Helmut
--- a/debian/patches/gcc-multiarch.diff
+++ b/debian/patches/gcc-multiarch.diff
@@ -145,6 +145,23 @@ Index: b/src/gcc/config.gcc
mips64*-*-linux* | mipsisa64*-*-linux*)
default_mips_abi=n32
enable_mips_multilibs="yes"
+@@ -3002,6 +3011,16 @@
+ tm_file="${tm_file} rs6000/option-defaults.h"
+ esac
+
++# non-glibc systems
++case ${target} in
++*-linux-musl*)
++ tmake_file="${tmake_file} t-musl"
++ ;;
++*-linux-uclibc*)
++ tmake_file="${tmake_file} t-uclibc"
++ ;;
++esac
++
+ # Build mkoffload tool
+ case ${target} in
+ *-intelmic-* | *-intelmicemul-*)
@@ -4507,7 +4516,7 @@ case ${target} in
i[34567]86-*-darwin* | x86_64-*-darwin*)
;;
@@ -214,3 +231,13 @@ Index: b/src/gcc/config/tilegx/t-tilegx
# Directory for prefix to system directories, for
# each of $(system_prefix)/usr/include, $(system_prefix)/usr/lib, etc.
+--- /dev/null
b/src/gcc/config/t-musl
+@@ -0,0 +1,2 @@
++MULTIARCH_DIRNAME := $(subst -linux-gnu,-linux-musl,$(MULTIARCH_DIRNAME))
++MULTILIB_OSDIRNAMES := $(subst -linux-gnu,-linux-musl,$(MULTILIB_OSDIRNAMES))
+--- /dev/null
b/src/gcc/config/t-uclibc
+@@ -0,0 +1,2 @@
++MULTIARCH_DIRNAME := $(subst -linux-gnu,-linux-uclibc,$(MULTIARCH_DIRNAME))
++MULTILIB_OSDIRNAMES := $(subst -linux-gnu,-linux-uclibc,$(MULTILIB_OSDIRNAMES))
Bug#859938: gcc-7: DEB_STAGE=rtlibs build not installable: unsatisfiable dependencies on gcc-7-cross-base
Source: gcc-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Building gcc libraries with DEB_STAGE=rtlibs is now successful. Yet the
resulting packages are not currently installable. See e.g.:
> Setting up gcc-7-base:tilegx (7-20170316-1) ...
> dpkg: dependency problems prevent configuration of libgcc1-dbg:tilegx:
> libgcc1-dbg:tilegx depends on gcc-7-cross-base (= 7-20170316-1).
>
> dpkg: error processing package libgcc1-dbg:tilegx (--install):
> dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of libgcc1:tilegx:
> libgcc1:tilegx depends on gcc-7-cross-base (= 7-20170316-1).
>
> dpkg: error processing package libgcc1:tilegx (--install):
> dependency problems - leaving unconfigured
While my previous patch #857074 fixed the inconsistency between
debian/control and p_base during package build, the emitted dependencies
still reference the -cross-base. Those are generated in
debian/control.m4 (BASELDEP and SOFTBASELDEP). Since we are in the case
where TARGET is defined, we end up injecting the "-cross" that is
necessary for cross compiler builds. I propose suppressing it when
CROSS_ARCH isn't all, because all cross compiler builds set CROSS_ARCH
to all. The attached patch does just that. What do you think?
Helmut
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -123,8 +123,8 @@
define(`SOFTBASEDEP', `gcc`'PV`'TS-base (>= ${gcc:SoftVersion})')
ifdef(`TARGET',`
-define(`BASELDEP', `gcc`'PV-cross-base`'GCC_PORTS_BUILD (= ${gcc:Version})')
-define(`SOFTBASELDEP', `gcc`'PV-cross-base`'GCC_PORTS_BUILD (>= ${gcc:SoftVersion})')
+define(`BASELDEP', `gcc`'PV`'ifelse(CROSS_ARCH,`all',`-cross')-base`'GCC_PORTS_BUILD (= ${gcc:Version})')
+define(`SOFTBASELDEP', `gcc`'PV`'ifelse(CROSS_ARCH, `all',`-cross')-base`'GCC_PORTS_BUILD (>= ${gcc:SoftVersion})')
',`dnl
define(`BASELDEP', `BASEDEP')
define(`SOFTBASELDEP', `SOFTBASEDEP')
Bug#857535: gcc-7 wrongly "fixes" limits.h when built against a mutiarch libc
Source: gcc-7 Severity: wishlist Tags: patch Control: block 798955 by -1 User: helm...@debian.org Usertags: rebootstrap For coinstalling multiple libcs (e.g. any-gnu-any-any and any-musl-any-any) or coinstalling glibc for different kernels (e.g. linux-any and kfreebsd-any), it is necessary to move standard libc headers (e.g. limits.h) to a multiarch location as they differ across these configurations. There is bug #798955 to implement this for glibc. Once #798955 is fixed, gcc-7's fixincludes will wrongly fix limits.h, because gcc determines its presence using a LIMITS_H_TEST that does not consider such locations. Thus gcc's limits.h will not include glibc's and set some macros differently. That leads to conflicts with other glibc headers and thus to compilation failures in e.g. dash. Changing LIMITS_H_TEST test to consider such paths causes gcc to properly include glibc's limits.h again. I thus propose appending the attached patch to debian/patches/gcc-multiarch.diff. The issue affects all versions of gcc, but I believe that there is no gain in fixing it for any versions < 7. Helmut --- a/src/gcc/Makefile.in +++ b/src/gcc/Makefile.in @@ -494,7 +494,7 @@ STMP_FIXINC = @STMP_FIXINC@ # Test to see whether exists in the system header files. -LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ] +LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h -o -f $(BUILD_SYSTEM_HEADER_DIR)/$(MULTIARCH_DIRNAME)/limits.h ] # Directory for prefix to system directories, for # each of $(system_prefix)/usr/include, $(system_prefix)/usr/lib, etc.
Bug#857074: gcc-7: fails to build with DEB_STAGE=rtlibs: dpkg-gencontrol: error: package gcc-7--base not in control info
Source: gcc-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
trying to build gcc-7 with DEB_STAGE=rtlibs results in an error over
here. A nios2 build[1] fails with:
| DEB_HOST_ARCH=nios2 dh_gencontrol -pgcc-7-nios2-linux-gnu-base --
-v7-20170226-1 '-Vlibgcc:Version=1:7-20170226-1' '-Vgcc:Version=7-20170226-1'
'-Vgcc:EpochVersion=1:7-20170226-1' '-Vgcc:SoftVersion=7' '-Vgdc:Version='
'-Vgnat:Version=7-20170226-1' '-Vgnat:SoftVersion=7' '-Vbinutils:Version=2.28'
'-Vdep:libgcc=libgcc1 (>= 1:7-20170226-1)' '-Vdep:libgccdev=libgcc-7-dev (=
7-20170226-1)' '-Vdep:libgccbiarch=' '-Vdep:libgccbiarchdev=' '-Vdep:libc=libc6
(>= 2.11)' '-Vdep:libcdev=libc6-dev (>= 2.13-5)' '-Vdep:libcbiarch='
'-Vdep:libcbiarchdev=' '-Vdep:libunwinddev=' '-Vdep:libcxxbiarchdev='
'-Vdep:libcxxbiarchdbg=' '-Vdep:libgnat=' '-Vbase:Breaks=gcc-4.4-base (<<
4.4.7), gcc-4.7-base (<< 4.7.3), gcj-4.4-base (<< 4.4.6-9~), gnat-4.4-base (<<
4.4.6-3~), gcj-4.6-base (<< 4.6.1-4~), gnat-4.6 (<< 4.6.1-5~)'
'-Vdep:libgomp=libgomp1 (>= ${gcc:Version})' '-Vdep:libatomic=libatomic1 (>=
${gcc:Version})' '-Vdep:libx32z=' '-Vdep:gdccross=gdc-7 (>= 7)'
'-Vdep:libcc1=libcc1-0 (>= ${gcc:SoftVersion})' '-Vconfl:lib32=libc6-i386 (<<
2.9-22)' '-Vmultiarch:breaks=gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4),
gcc-4.5 (<< 4.5.3-2)' '-Vgolang:Conflicts=golang-go (<< 2:1.3.3-1ubuntu2)'
'-VBuilt-Using=' '-Vfortran:mod-version=gfortran-mod-14'
| install -d debian/gcc-7-nios2-linux-gnu-base/DEBIAN
| echo misc:Depends= >> debian/gcc-7-nios2-linux-gnu-base.substvars
| echo misc:Pre-Depends= >> debian/gcc-7-nios2-linux-gnu-base.substvars
| dpkg-gencontrol -pgcc-7-nios2-linux-gnu-base -ldebian/changelog
-Tdebian/gcc-7-nios2-linux-gnu-base.substvars
-Pdebian/gcc-7-nios2-linux-gnu-base -v7-20170226-1
-Vlibgcc:Version=1:7-20170226-1 -Vgcc:Version=7-20170226-1
-Vgcc:EpochVersion=1:7-20170226-1 -Vgcc:SoftVersion=7 -Vgdc:Version=
-Vgnat:Version=7-20170226-1 -Vgnat:SoftVersion=7 -Vbinutils:Version=2.28
"-Vdep:libgcc=libgcc1 (>= 1:7-20170226-1)" "-Vdep:libgccdev=libgcc-7-dev (=
7-20170226-1)" -Vdep:libgccbiarch= -Vdep:libgccbiarchdev= "-Vdep:libc=libc6 (>=
2.11)" "-Vdep:libcdev=libc6-dev (>= 2.13-5)" -Vdep:libcbiarch=
-Vdep:libcbiarchdev= -Vdep:libunwinddev= -Vdep:libcxxbiarchdev=
-Vdep:libcxxbiarchdbg= -Vdep:libgnat= "-Vbase:Breaks=gcc-4.4-base (<< 4.4.7),
gcc-4.7-base (<< 4.7.3), gcj-4.4-base (<< 4.4.6-9~), gnat-4.4-base (<<
4.4.6-3~), gcj-4.6-base (<< 4.6.1-4~), gnat-4.6 (<< 4.6.1-5~)"
"-Vdep:libgomp=libgomp1 (>= \${gcc:Version})" "-Vdep:libatomic=libatomic1 (>=
\${gcc:Version})" -Vdep:libx32z= "-Vdep:gdccross=gdc-7 (>= 7)"
"-Vdep:libcc1=libcc1-0 (>= \${gcc:SoftVersion})" "-Vconfl:lib32=libc6-i386 (<<
2.9-22)" "-Vmultiarch:breaks=gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4),
gcc-4.5 (<< 4.5.3-2)" "-Vgolang:Conflicts=golang-go (<< 2:1.3.3-1ubuntu2)"
-VBuilt-Using= -Vfortran:mod-version=gfortran-mod-14
| dpkg-gencontrol: error: package gcc-7-nios2-linux-gnu-base not in control info
| dh_gencontrol: dpkg-gencontrol -pgcc-7-nios2-linux-gnu-base
-ldebian/changelog -Tdebian/gcc-7-nios2-linux-gnu-base.substvars
-Pdebian/gcc-7-nios2-linux-gnu-base -v7-20170226-1
-Vlibgcc:Version=1:7-20170226-1 -Vgcc:Version=7-20170226-1
-Vgcc:EpochVersion=1:7-20170226-1 -Vgcc:SoftVersion=7 -Vgdc:Version=
-Vgnat:Version=7-20170226-1 -Vgnat:SoftVersion=7 -Vbinutils:Version=2.28
-Vdep:libgcc=libgcc1 (>= 1:7-20170226-1) -Vdep:libgccdev=libgcc-7-dev (=
7-20170226-1) -Vdep:libgccbiarch= -Vdep:libgccbiarchdev= -Vdep:libc=libc6 (>=
2.11) -Vdep:libcdev=libc6-dev (>= 2.13-5) -Vdep:libcbiarch=
-Vdep:libcbiarchdev= -Vdep:libunwinddev= -Vdep:libcxxbiarchdev=
-Vdep:libcxxbiarchdbg= -Vdep:libgnat= -Vbase:Breaks=gcc-4.4-base (<< 4.4.7),
gcc-4.7-base (<< 4.7.3), gcj-4.4-base (<< 4.4.6-9~), gnat-4.4-base (<<
4.4.6-3~), gcj-4.6-base (<< 4.6.1-4~), gnat-4.6 (<< 4.6.1-5~)
-Vdep:libgomp=libgomp1 (>= ${gcc:Version}) -Vdep:libatomic=libatomic1 (>=
${gcc:Version}) -Vdep:libx32z= -Vdep:gdccross=gdc-7 (>= 7)
-Vdep:libcc1=libcc1-0 (>= ${gcc:SoftVersion}) -Vconfl:lib32=libc6-i386 (<<
2.9-22) -Vmultiarch:breaks=gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5
(<< 4.5.3-2) -Vgolang:Conflicts=golang-go (<< 2:1.3.3-1ubuntu2) -VBuilt-Using=
-Vfortran:mod-version=gfortran-mod-14 returned exit code 255
When DEB_STAGE=rtlibs, debian/rules.defs sets the TS variable to an
empty string. This is propagated to m4 and thus the base package in
debian/control ends up without a target suffix. I think this is correct,
because rtlibs mostly tries to mimic a reduced cross build (not cross
compiler build). However, the make variable p_base includes the target
suffix as DEB_CROSS is set to yes. The attached patch fixes the value of
p_base when DEB_STAGE is set to rtlibs. Please consider applying it.
Helmut
[1] https://jenkins.debian.net/job/rebootstrap_nios2_gcc7_supported/3/console
--- a/debian/rules2
+++ b/debian/rules2
@@ -1822,7 +1822,7 @@
Bug#856452: gcc-7: allow disabling brig via nolang DEB_BUILD_OPTIONS
Source: gcc-7 Version: 7-20170221-1 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Hi Matthias, thank you for disabling brig in stage1 and stage2. It still is rightly enabled in the unstaged cross compiler build. Since it is not needed for bootstrapping, I'd like to disable brig entirely. That saves build time and human time for figuring out why it doesn't work. The gcc-N source package typically allows doing so by passing a suitable DEB_BUILD_OPTIONS=nolang=... variable. The attached patch allows disabling brig by passing brig in there. Please consider applying it. Helmut --- a/debian/rules.defs +++ a/debian/rules.defs @@ -843,6 +843,7 @@ with_brigdev := yes with_libhsailrt := yes endif +with_brig := $(call envfilt, brig, , , $(with_brig)) ifeq ($(with_brig),yes) enabled_languages += brig
Bug#855565: cross-install-location.diff no longer applies
Source: gcc-7 Version: 6.3.0-5 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I started trying cross toolchain builds with gcc-7 and quickly noticed that cross-install-location.diff hasn't been updated for gcc-7 yet. I am attaching a patch to that minimally updates it to apply again. After applying it, the cross toolchain bootstrap appears to mostly work. Helmut --- a/debian/patches/cross-install-location.diff +++ b/debian/patches/cross-install-location.diff @@ -61,7 +61,7 @@ @@ -255,7 +255,7 @@ with_libiberty = @with_libiberty@ ACLOCAL_AMFLAGS = -I .. -I ../config AUTOMAKE_OPTIONS = no-dependencies - gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) + gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) -libexecsubdir := $(libexecdir)/gcc/$(real_target_noncanonical)/$(gcc_version)$(accel_dir_suffix) +libexecsubdir := $(libexecdir)/gcc-cross/$(real_target_noncanonical)/$(gcc_version)$(accel_dir_suffix) AM_CPPFLAGS = -I$(top_srcdir)/../include $(DEFS) @@ -167,9 +167,9 @@ - -DSTANDARD_LIBEXEC_PREFIX=\"$(libexecdir)/gcc/\" \ + -DSTANDARD_EXEC_PREFIX=\"$(libdir)/gcc-cross/\" \ + -DSTANDARD_LIBEXEC_PREFIX=\"$(libexecdir)/gcc-cross/\" \ - -DDEFAULT_TARGET_VERSION=\"$(BASEVER_c)\" \ - -DDEFAULT_TARGET_FULL_VERSION=\"$(FULLVER_c)\" \ + -DDEFAULT_TARGET_VERSION=\"$(version)\" \ -DDEFAULT_REAL_TARGET_MACHINE=\"$(real_target_noncanonical)\" \ + -DDEFAULT_TARGET_MACHINE=\"$(target_noncanonical)\" \ @@ -2671,7 +2671,7 @@ PREPROCESSOR_DEFINES = \ -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \ -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\" \ @@ -251,7 +251,7 @@ @@ -68,7 +68,7 @@ GCC_DIR=$(MULTIBUILDTOP)../../$(host_sub target_noncanonical:=@target_noncanonical@ - version := $(shell cat $(srcdir)/../gcc/BASE-VER) + version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER) -libsubdir := $(libdir)/gcc/$(target_noncanonical)/$(version)$(MULTISUBDIR) +libsubdir := $(libdir)/gcc-cross/$(target_noncanonical)/$(version)$(MULTISUBDIR) ADA_RTS_DIR=$(GCC_DIR)/ada/rts$(subst /,_,$(MULTISUBDIR)) @@ -265,9 +265,9 @@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \ $(top_srcdir)/../include --fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude +-fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude -libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include -+fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/finclude ++fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude +libsubincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include AM_CPPFLAGS = $(addprefix -I, $(search_path)) AM_CFLAGS = $(XCFLAGS) @@ -280,9 +280,9 @@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \ $(top_srcdir)/../include --fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude +-fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude -libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include -+fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/finclude ++fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude +libsubincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include vpath % $(strip $(search_path)) @@ -307,7 +307,7 @@ @@ -8,6 +8,6 @@ EXTRA_DIST=ffi.h.in # Where generated headers like ffitarget.h get installed. - gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) + gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) -toollibffidir := $(libdir)/gcc/$(target_alias)/$(gcc_version)/include +toollibffidir := $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include @@ -319,7 +319,7 @@ @@ -251,7 +251,7 @@ EXTRA_DIST = ffi.h.in # Where generated headers like ffitarget.h get installed. - gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) + gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) -toollibffidir := $(libdir)/gcc/$(target_alias)/$(gcc_version)/include +toollibffidir := $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include toollibffi_HEADERS = ffi.h ffitarget.h
Bug#854159: gcc-6: disable libmpx in stage1 and stage2 builds
Source: gcc-6 Tags: patch User: helm...@debian.org Usertags: rebootstrap It was never possible to bootstrapp x86 architectures using gcc-6, because stage1 and stage2 compilers were never buildable. That's due to gcc-6 enabling libmpx by default. However, libmpx needs a working libc. Thus the staged builds should disable libmpx (like they are disabling libatomic, libgomp and libssp). Please consider applying the attached patch Helmut --- a/debian/rules2 +++ b/debian/rules2 @@ -221,6 +221,7 @@ --disable-decimal-float \ --disable-libatomic \ --disable-libgomp \ + --disable-libmpx \ --disable-libssp \ --disable-libquadmath \ --disable-libsanitizer \
Bug#851273: libstdc++-6-dev: error when installing together with libstdc++-6-dev:armel
Package: libstdc++-6-dev
Version: 6.3.0-1
Severity: important
User: helm...@debian.org
Usertags: rebootstrap
An attempt at installing libstdc++-6-dev:armel fails:
| # apt-get -y install libstdc++-6-dev libstdc++-6-dev:armel
| ...
| dpkg: error processing archive
/tmp/apt-dpkg-install-N1eyfh/12-libstdc++-6-dev_6.3.0-2_armel.deb (--unpack):
| trying to overwrite shared '/usr/include/c++/6/bits/exception_ptr.h', which
is different from other instances of package libstdc++-6-dev:armel
| dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
| Errors were encountered while processing:
| /tmp/apt-dpkg-install-N1eyfh/12-libstdc++-6-dev_6.3.0-2_armel.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)
This breaks cross build Debian packages to armel.
I am attaching a diff between the common files of the amd64 package and
the armel package. Based on that diff, I think that
debian/patches/pr64735.diff is the culprit. The patch is only added on
armel, because it changes symbols (which is bad enough). It was added to
fix #727621.
Given the age of the report and the regression, I think it is too late
for including it and thus ask for reverting it (i.e. reopening #727621)
or finding a solution that doesn't break cross compiling.
Thus I am adding d-arm@l.d.o via X-Debbugs-Cc.
Given that only four files are affected, all of them are headers and
all of them live below /usr/include/c++/6/, a solution could be moving
them to multiarch locations. The offending headers are
bits/exception_ptr.h, bits/nested_exception.h exception and future. This
risks introducing other regressions though.
Another option would be reworking the patch to be applicable for every
architecture but being a noop for everything but armel.
Given the timing, a revert sounds like the best available option to me.
Do any armel porters disagree?
Helmut
--- amd64/usr/include/c++/6/bits/exception_ptr.h
+++ armel/usr/include/c++/6/bits/exception_ptr.h
@@ -36,10 +36,6 @@
#include
#include
-#if ATOMIC_INT_LOCK_FREE < 2
-# error This platform does not support exception propagation.
-#endif
-
extern "C++" {
namespace std
--- amd64/usr/include/c++/6/bits/nested_exception.h
+++ armel/usr/include/c++/6/bits/nested_exception.h
@@ -39,10 +39,6 @@
#include
#include
-#if ATOMIC_INT_LOCK_FREE < 2
-# error This platform does not support exception propagation.
-#endif
-
extern "C++" {
namespace std
--- amd64/usr/include/c++/6/exception
+++ armel/usr/include/c++/6/exception
@@ -35,7 +35,6 @@
#pragma GCC visibility push(default)
#include
-#include
extern "C++" {
@@ -166,7 +165,7 @@
#pragma GCC visibility pop
-#if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1)
+#if (__cplusplus >= 201103L)
#include
#include
#endif
--- amd64/usr/include/c++/6/future
+++ armel/usr/include/c++/6/future
@@ -182,8 +182,7 @@
future<__async_result_of<_Fn, _Args...>>
async(_Fn&& __fn, _Args&&... __args);
-#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) \
- && (ATOMIC_INT_LOCK_FREE > 1)
+#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
/// Base class and enclosing scope.
struct __future_base
@@ -1745,7 +1744,6 @@
#endif // _GLIBCXX_ASYNC_ABI_COMPAT
#endif // _GLIBCXX_HAS_GTHREADS && _GLIBCXX_USE_C99_STDINT_TR1
- // && ATOMIC_INT_LOCK_FREE
// @} group futures
_GLIBCXX_END_NAMESPACE_VERSION
Bug#847123: mark autoconf2.64 Multi-Arch: foreign
Package: autoconf2.64
Version: 2.64+dfsg-0.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:gcc-5 src:gcc-6 src:gcc-arm-none-eabi src:gcc-avr
src:gcc-snapshot src:kyototycoon
The packages listed above fail to satisfy their cross build
dependencies, because their dependency on autoconf2.64 is unsatisfiable.
In general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign. In this case, such a
marking is correct, because autoconf2.64 does not have any maintainer
scripts and it does not expose any of its dependencies:
* m4 is Multi-Arch: foreign
* debianutils is Multi-Arch: foreign
* autoconf is Multi-Arch: foreign
* perl is Multi-Arch: allowed
* libfile-temp-perl is provided by perl-base, which is Multi-Arch: no
Thus it can only expose architecture awareness via perl, but perl is
only used for executing scripts as is done in e.g. autoconf.
Helmut
diff -u autoconf2.64-2.64+dfsg/debian/changelog
autoconf2.64-2.64+dfsg/debian/changelog
--- autoconf2.64-2.64+dfsg/debian/changelog
+++ autoconf2.64-2.64+dfsg/debian/changelog
@@ -1,3 +1,10 @@
+autoconf2.64 (2.64+dfsg-0.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark autoconf2.64 Multi-Arch: foreign (Closes: #-1)
+
+ -- Helmut Grohne <hel...@subdivi.de> Mon, 05 Dec 2016 20:39:56 +0100
+
autoconf2.64 (2.64+dfsg-0.1) unstable; urgency=medium
* Non-maintainer upload.
diff -u autoconf2.64-2.64+dfsg/debian/control
autoconf2.64-2.64+dfsg/debian/control
--- autoconf2.64-2.64+dfsg/debian/control
+++ autoconf2.64-2.64+dfsg/debian/control
@@ -9,6 +9,7 @@
Package: autoconf2.64
Architecture: all
+Multi-Arch: foreign
Depends: m4, debianutils (>= 1.8), autoconf (>= 2.50), perl,
libfile-temp-perl, ${misc:Depends}
Replaces: autoconf (<< 2.50)
Conflicts: autoconf (<< 2.50)
Bug#773065: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#838316: Removed package(s) from unstable)
Control: reopen -1 Control: reassign -1 src:gcc-6 On Tue, Sep 20, 2016 at 10:19:12PM +, Debian Bug Tracking System wrote: > Please allow selecting the target architecture using "dpkg-buildpackage > --target-arch" again. This ability was removed in 4.9.2-7 when #768167 > was fixed. > > I am attaching a diff that enables target selection via: > * dpkg-buildpackage --target-arch > * debian/target > * DEB_GCC_TARGET As far as I can tell, the issue is still present in later versions and a rebased patch is available from cross-gcc-dev (e.g. http://sources.debian.net/src/cross-gcc/101/patches/gcc-6/0006-Allow-target-selection-via-dpkg-buildpackage-target-.patch/). Thus reopening. Helmut
Bug#827578: gcc-6: please support the tilegx architecture
Source: gcc-6
Version: 6.1.1-6
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
can you add support for the tilegx architecture to gcc-6?
State of tilegx:
* Waiting for inclusion into dpkg: #823167
* Supported in linux-libc-dev: #824524 #823632
* Two glibc patches pending submission
* With all of the above, the cross toolchain can be bootstrapped.
* In general, tilegx is supported upstream very well.
Changes needed in the gcc packaging:
* The usual gcc-multiarch.diff hunk required for every single
architecture.
* Tell libgcc about the tilegx-specific header feedback.h.
* Disable multilib to keep things simple. If someone really wants
tilepro, we should add another architecture and use cross toolchains
instead.
Thanks for considering
Helmut
diff --git a/debian/patches/gcc-multiarch.diff b/debian/patches/gcc-multiarch.diff
index 7e34ff6..6802a73 100644
--- a/debian/patches/gcc-multiarch.diff
+++ b/debian/patches/gcc-multiarch.diff
@@ -169,3 +169,14 @@ Index: b/src/gcc/config/mips/mips.h
/* Load store bonding is not supported by micromips and fix_24k. The
performance can be degraded for those targets. Hence, do not bond for
micromips or fix_24k. */
+--- a/src/gcc/config/tilegx/t-tilegx
a/src/gcc/config/tilegx/t-tilegx
+@@ -1,6 +1,7 @@
+ MULTILIB_OPTIONS = m64/m32
+ MULTILIB_DIRNAMES = 64 32
+-MULTILIB_OSDIRNAMES = ../lib ../lib32
++MULTILIB_OSDIRNAMES = ../lib$(call if_multiarch,:tilegx-linux-gnu) ../lib32$(call if_multiarch,:tilegx32-linux-gnu)
++MULTIARCH_DIRNAME = $(call if_multiarch,tilegx-linux-gnu)
+
+ LIBGCC = stmp-multilib
+ INSTALL_LIBGCC = install-multilib
diff --git a/debian/rules.d/binary-libgcc.mk b/debian/rules.d/binary-libgcc.mk
index ce9a2bd..ca25058 100644
--- a/debian/rules.d/binary-libgcc.mk
+++ b/debian/rules.d/binary-libgcc.mk
@@ -96,6 +96,10 @@ ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64 ppc64el p
header_files += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h,spe.h}
endif
+ifeq ($(DEB_TARGET_ARCH),tilegx)
+header_files += $(gcc_lib_dir)/include/feedback.h
+endif
+
p_lgcc = libgcc$(GCC_SONAME)$(cross_lib_arch)
p_lgccdbg = libgcc$(GCC_SONAME)-dbg$(cross_lib_arch)
p_lgccdev = libgcc-$(BASE_VERSION)-dev$(cross_lib_arch)
diff --git a/debian/rules2 b/debian/rules2
index abe987b..0f3eddc 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -559,6 +559,10 @@ ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
CONFARGS += --disable-multilib
endif
+ifneq (,$(filter tilegx,$(DEB_TARGET_GNU_CPU)))
+ CONFARGS += --disable-multilib
+endif
+
ifeq ($(derivative),Ubuntu)
ifneq (,$(findstring s390x-linux,$(DEB_TARGET_GNU_TYPE)))
CONFARGS += --with-arch=zEC12
Bug#823894: please detect hard float for non-linux or non-glibc arm-*-*eabihf builds (e.g. musl)
Source: gcc-6 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, This is my second patch for musl. This time it is about musl-linux-armhf only. The gcc packaging has some matching logic for setting make variables such as $(float_abi). Since they currently match for armhf, they do not cover non-linux or non-glibc arm-*-*eabihf configurations. This causes hard to diagnose build failures down the road (thanks to Waldemar Brodkorb for explaining the cause). The attached patch broadens the matching logic to cover these cases and should also address uclibc-linux-armhf and kfreebsd-armhf if they ever materialize. Do you agree with the proposed change? Helmut --- a/debian/rules.defs +++ b/debian/rules.defs @@ -376,7 +376,7 @@ endif # check if we're building for armel or armhf -ifeq ($(DEB_TARGET_ARCH),armhf) +ifneq (,$(filter %eabihf,$(DEB_TARGET_GNU_SYSTEM))) float_abi := hard else ifneq (,$(filter $(distribution)-$(DEB_TARGET_ARCH), Ubuntu-armel)) ifneq (,$(filter $(distrelease),lucid maverick natty oneiric precise)) --- a/debian/rules2 +++ b/debian/rules2 @@ -483,7 +483,7 @@ CONFARGS += --disable-sjlj-exceptions # FIXME: libjava is not ported for thumb, this hack only works for # separate gcj builds - ifneq (,$(filter armhf,$(DEB_TARGET_ARCH))) + ifneq (,$(filter %armhf,$(DEB_TARGET_ARCH))) ifeq ($(distribution),Raspbian) with_arm_arch = armv6 with_arm_fpu = vfp
Bug#823769: please support the musl c library for cross compiler builds
Source: gcc-6 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I've been working on bootstrapping a musl-based port for a while now and think that some patches are sufficiently stable that they can go upstream already. One of the obstacles here is the strange naming of musl packages. The C library is just called "musl" and the development package is called "musl-dev". Neither the naming nor the versioning matches glibc, so the resulting packages are not installable. I am attaching a patch that updates $(LIBC_DEP), $(libc_ver) and $(libc_dev_ver) to match musl. Please consider applying it. Other than this patch not much is missing for musl support. As far as I can see, a gcc upstream change to src/libstdc++-v3/configure.host is still trickling down and the hard-float detection is broken for musl. Neither of which are subject of this bug. I just list those here to get you an impression of how much is missing. Helmut diff -u a/debian/rules.conf b/debian/rules.conf --- a/debian/rules.conf +++ b/debian/rules.conf @@ -240,6 +240,11 @@ else LIBC_DEP = libc6 endif + ifneq (,$(findstring musl-linux-,$(DEB_TARGET_ARCH))) +LIBC_DEP = musl +libc_ver = 0.9 +libc_dev_ver = 0.9 + endif else ifeq ($(DEB_TARGET_ARCH_OS),hurd) LIBC_DEP = libc0.3
