Bug#1029958: cross-gcc-dev: gcc-13: update hunk context
Source: cross-gcc Version: 247 Tags: patch User: helm...@debian.org Usertags: rebootstrap Patch application started failing for gcc-13. It's a trivial hunk context update. Helmut diff --minimal -Nru cross-gcc-247/debian/changelog cross-gcc-247+nmu1/debian/changelog --- cross-gcc-247/debian/changelog 2023-01-26 08:32:03.0 +0100 +++ cross-gcc-247+nmu1/debian/changelog 2023-01-28 20:11:48.0 +0100 @@ -1,3 +1,10 @@ +cross-gcc (247+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Update hunk context for gcc-13 patches. (Closes: #-1) + + -- Helmut Grohne Sat, 28 Jan 2023 20:11:48 +0100 + cross-gcc (247) unstable; urgency=medium * rebuild for 13-20230114-1 diff --minimal -Nru cross-gcc-247/patches/gcc-13/0004-added-multi-arch-specific-install-location-patch.patch cross-gcc-247+nmu1/patches/gcc-13/0004-added-multi-arch-specific-install-location-patch.patch --- cross-gcc-247/patches/gcc-13/0004-added-multi-arch-specific-install-location-patch.patch 2023-01-26 08:32:03.0 +0100 +++ cross-gcc-247+nmu1/patches/gcc-13/0004-added-multi-arch-specific-install-location-patch.patch 2023-01-28 20:11:36.0 +0100 @@ -480,9 +480,9 @@ + else +debian_patches += cross-install-location + endif - ifeq ($(with_m2),yes) - debian_patches += cross-install-location-gm2 - endif + endif + + ifeq ($(DEB_TARGET_ARCH_OS),hurd) -- 2.31.1
Bug#1028094: support gcc-13
Package: cross-gcc-dev Hi, gcc-13 has entered experimental. Please copy over the gcc-12 patches for gcc-13. It would be nice if you could rebase them to be applicable, but as usual, I don't expect them to work in any way and will file patches. Helmut
Bug#977944: add support for gcc-11
Package: cross-gcc-dev User: helm...@debian.org Usertags: rebootstrap Initial please add support for gcc-11. As usual, I don't expect it to work. Just make it apply (on the outer level), I'll send fixes for further issues. Helmut
Bug#956855: consider reducing toolchain bootstrap stages
Source: cross-toolchain-base
Version: 45
Severity: wishlist
Tags: patch moreinfo
I'm not sure anymore who told me, but glibc has a build_many_glibcs.py
script and it does the toolchain bootstrap dance with fewer stages than
Debian (i.e. cross-toolchain-base and rebootstrap) does. The current
Debian toolchain bootstrap looks like this:
* binutils
* linux-libc-dev
* gcc stage1 (bare metal)
* glibc stage1 (headers + stub libc.so)
* gcc stage2
* glibc stage2 (libc without systemtap and other optional features)
* gcc stage3 (libc-integrated cross compiler)
* gcc rtlibs (runtime libraries for the cross compiler)
The assertion is that we can skip glibc stage1 and gcc stage2 and go
directly from gcc stage1 to glibc stage2.
I've implemented this in rebootstrap and it seems to work reasonably
well for a number of architectures. I've not run it on the full test
matrix yet. Some observations on rebootstrap:
* musl-linux-any already works like this since a while.
* hurd-any formerly needed libihash-dev for libpthread, but no longer
does. This sequence also works on hurd-i386.
* I've had success with arm64, armel, armhf, m68k, mips (nobiarch),
mipsel (nobiarch) and ppc64el thus far. Notably, these all lack
multilibs and I'm still sorting out multilib issues.
* I cannot tell about kfreebsd-any, since they didn't manage to get the
relevant kernel header source package back into unstable yet.
I've implemented this for cross-toolchain-base (patch attached) and a
performed a successful testbuild. Using diffoscope to compare the
resulting packages with the ones from the archive was not a useful thing
to do as the build-ids changed.
So what do you think about going to fewer stages? I'd like to solicit
explicit feedback from the involved parties:
gcc maintainers / Matthias:
* Do you have any objections to reducing stages?
* Should we delete gcc stage2?
* Should we rename gcc stage3 to gcc stage2?
glibc maintainers / Aurelien:
* Do you have any objections to reducing stages?
* Should we delete glibc stage1?
* Should we rename glibc stage2 to glibc stage1?
* Should we maybe split stage2 into a number of profiles
pkg.glibc.noselinux, pkg.glibc.noxen, pkg.glibc.noalphaev,
pkg.glibc.noxcryptdep?
Due to these open questions, I've tagged the bug moreinfo.
Helmut
diff --minimal -Nru cross-toolchain-base-45/debian/changelog
cross-toolchain-base-45+nmu1/debian/changelog
--- cross-toolchain-base-45/debian/changelog2020-03-22 14:02:54.0
+0100
+++ cross-toolchain-base-45+nmu1/debian/changelog 2020-04-15
11:35:18.0 +0200
@@ -1,3 +1,10 @@
+cross-toolchain-base (45+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Bootstrap with fewer stages. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 15 Apr 2020 11:35:18 +0200
+
cross-toolchain-base (45) unstable; urgency=medium
* Build using glibc 2.30-2.
diff --minimal -Nru cross-toolchain-base-45/debian/rules
cross-toolchain-base-45+nmu1/debian/rules
--- cross-toolchain-base-45/debian/rules2020-03-22 14:02:01.0
+0100
+++ cross-toolchain-base-45+nmu1/debian/rules 2020-04-15 11:35:18.0
+0200
@@ -343,96 +344,6 @@
ln -sf ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
endef
-$(stamp)build-gcc2.%: $(stamp)init-gcc $(stamp)install-glibc1.%
- @echo START $@
- cd debian/tmp.${CROSS_ARCH}/$(PF)/bin/ && \
- rm -f ${CROSS_GNU_TYPE}-gcc-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcc && \
- rm -f ${CROSS_GNU_TYPE}-cpp-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-cpp && \
- rm -f ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
- cd gcc && \
- PATH=${CURDIR}/debian/tmp.${CROSS_ARCH}/$(PF)/bin:${PATH} \
- LD_LIBRARY_PATH=$(call
binutils_ldpath,$*):${CURDIR}/debian/tmp.${CROSS_ARCH}/usr/lib:${CURDIR}/debian/tmp.${CROSS_ARCH}/lib
\
- DH_VERBOSE=1 \
- WITH_SYSROOT=/ \
- WITH_BUILD_SYSROOT=${CURDIR}/debian/tmp.${CROSS_ARCH} \
- DEB_STAGE=stage2 \
- PKG_IGNORE_CURRENTLY_BUILDING=1 \
- BACKPORT=false \
- DEB_BUILD_OPTIONS="$(DEB_BUILD_OPTIONS) nocheck nopgo nolto nohppa64
nojit nonvptx" \
- WITHOUT_LANG="hppa64 jit nvptx" \
- $(if $(filter $(HOST_ARCH),$(CROSS_ARCH)),FORCE_CROSS_LAYOUT=yes
WITH_BOOTSTRAP=off) \
- dpkg-buildpackage -b -uc -us -d
- touch $@
-
-$(stamp)install-gcc2.%: $(stamp)build-gcc2.%
- @echo START $@
- $(call install_gcc)
- dpkg-deb -x libgcc[124]-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian/tmp.${CROSS_ARCH}
-ifneq (,$(ARM32_MULTILIBS))
- $(if $(filter $(CROSS_ARCH),armhf), \
- dpkg-deb -x libsfgcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian/tmp.${CROSS_ARCH}; \
- dpkg-deb -x
libsfgcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian
Bug#951470: cross-ma-install-location.diff no longer applies to gcc-10
Package: cross-gcc-dev
Version: 242
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Dima,
cross-ma-install-location.diff no longer applies during gcc-10. I'm
attaching an updated version that applies cleanly to gcc-10. I'm not
entirely sure that it is fully correct, because the build fails with a
symbols error in the end. However, the supported cross compiler build
fails in the same way. Can you replace the existing
cross-ma-install-location.diff with the attached version for gcc-10?
Helmut
Index: b/src/libada/configure.ac
===
--- a/src/libada/configure.ac
+++ b/src/libada/configure.ac
@@ -65,22 +65,8 @@
toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
;;
no)
-if test -n "$with_cross_host" &&
- test x"$with_cross_host" != x"no"; then
- # Install a library built with a cross compiler in tooldir, not libdir.
- toolexecdir='$(exec_prefix)/$(target_alias)'
- case ${with_toolexeclibdir} in
- no)
- toolexeclibdir='$(toolexecdir)/lib'
- ;;
- *)
- toolexeclibdir=${with_toolexeclibdir}
- ;;
- esac
-else
- toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
- toolexeclibdir='$(libdir)'
-fi
+toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
+toolexeclibdir='$(libdir)'
multi_os_directory=`$CC -print-multi-os-directory`
case $multi_os_directory in
.) ;; # Avoid trailing /.
Index: b/src/libffi/configure.ac
===
--- a/src/libffi/configure.ac
+++ b/src/libffi/configure.ac
@@ -497,21 +497,9 @@
AC_DEFINE(USING_PURIFY, 1, [Define this if you are using Purify and want to suppress spurious messages.])
fi)
-if test -n "$with_cross_host" &&
- test x"$with_cross_host" != x"no"; then
- toolexecdir='$(exec_prefix)/$(target_alias)'
- case ${with_toolexeclibdir} in
-no)
- toolexeclibdir='$(toolexecdir)/lib'
- ;;
-*)
- toolexeclibdir=${with_toolexeclibdir}
- ;;
- esac
-else
- toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
- toolexeclibdir='$(libdir)'
-fi
+toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
+toolexeclibdir='$(libdir)'
+
multi_os_directory=`$CC -print-multi-os-directory`
case $multi_os_directory in
.) ;; # Avoid trailing /.
Index: b/src/libgcc/configure.ac
===
--- a/src/libgcc/configure.ac
+++ b/src/libgcc/configure.ac
@@ -95,15 +95,6 @@
slibdir="$with_slibdir",
if test "${version_specific_libs}" = yes; then
slibdir='$(libsubdir)'
-elif test -n "$with_cross_host" && test x"$with_cross_host" != x"no"; then
- case ${with_toolexeclibdir} in
-no)
- slibdir='$(exec_prefix)/$(host_noncanonical)/lib'
- ;;
-*)
- slibdir=${with_toolexeclibdir}
- ;;
- esac
else
slibdir='$(libdir)'
fi)
@@ -141,22 +132,8 @@
toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
;;
no)
-if test -n "$with_cross_host" &&
- test x"$with_cross_host" != x"no"; then
- # Install a library built with a cross compiler in tooldir, not libdir.
- toolexecdir='$(exec_prefix)/$(target_noncanonical)'
- case ${with_toolexeclibdir} in
- no)
- toolexeclibdir='$(toolexecdir)/lib'
- ;;
- *)
- toolexeclibdir=${with_toolexeclibdir}
- ;;
- esac
-else
- toolexecdir='$(libdir)/gcc-lib/$(target_noncanonical)'
- toolexeclibdir='$(libdir)'
-fi
+toolexecdir='$(libdir)/gcc-lib/$(target_noncanonical)'
+toolexeclibdir='$(libdir)'
multi_os_directory=`$CC -print-multi-os-directory`
case $multi_os_directory in
.) ;; # Avoid trailing /.
Index: b/src/libgfortran/configure.ac
===
--- a/src/libgfortran/configure.ac
+++ b/src/libgfortran/configure.ac
@@ -98,22 +98,8 @@
toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
;;
no)
-if test -n "$with_cross_host" &&
- test x"$with_cross_host" != x"no"; then
- # Install a library built with a cross compiler in tooldir, not libdir.
- toolexecdir='$(exec_prefix)/$(target_alias)'
- case ${with_toolexeclibdir} in
- no)
- toolexeclibdir='$(toolexecdir)/lib'
- ;;
- *)
- toolexeclibdir=${with_toolexeclibdir}
- ;;
- esac
-else
- toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
- toolexeclibdir='$(libdir)'
-fi
+toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
+toolexeclibdir='$(libdir)'
multi_os_directory=`$CC -print-multi-os-directory`
case $multi_os_directory in
.) ;; # Avoid trailing /.
Index: b/src/libgo/configure.ac
===
--- a/src/libgo/configure.ac
+++ b/src/libgo/configure.ac
@@ -80,21 +80,8 @@
# Calculate glibgo_toolexecdir, glibgo_toolexeclibdir
# Install a library built with a cross compiler in tooldir, not
Bug#947235: port patches to gcc-10
Package: cross-gcc-dev Severity: important User: helm...@debian.org Usertags: rebootstrap Please add an initial patch stack for gcc-10 from experimental. If it doesn't work, I'll send patches to make it work. Just make it available soon please. If you also check that the patches apply, that could save a few round trips. Thank you. Helmut
Re: state of mipsen cross toolchains
Hi Matthias, On Mon, Oct 28, 2019 at 09:28:14PM +0100, Matthias Klose wrote: > If you think, there is coordination needed, then you were probably not aware > of dropping mips as a release architecture and not adding it as a port. I'm sorry, my previous mail contained a very misleading typo. Where I wrote "crossbuild-essential-mips", I actually meant "crossbuild-essential-mipsel". No, I'm not trying to get "mips" back. Due to this typo, your answer does not answer any of my questions. I'm actually interested in the fate of the remaining release mipsen architectures. Or maybe I'm missing plans to remove all mipsen as release architectures? > The move of the remaining two mips* targets to -cross-mipsen were > coordinated with YunQiang Su, however I didn't expect him adding back mips. It's great that you coordinated it with YunQiang Su. However coordinating the development of cross toolchains with debian-cross would seem to be a fairly obvious thing to do, no? Especially if your changes render cross toolchains unusable for months. Helmut
state of mipsen cross toolchains
Hi, around September 13th, support for cross building packages for mipsen (i.e. crossbuild-essential-*) was removed from unstable without any coordination with debian-cr...@lists.debian.org. Since then, I inquired multiple times on the state of these cross toolchains without any useful replies. I see that we now have binutils-mipsen, gcc-9-cross-mipsen, gcc-defaults-mipsen, but no build-essential-mipsen. What is the plan for crossbuild-essential-mips and crossbuild-essential-mips64el? Are these supposed to come back eventually? If so, when? In the absence of these packages, should I remove support for mipsen from crossqa.debian.net? Helmut
Bug#936092: gcc-9 patches apply even less
Source: cross-gcc Version: 231 Severity: serious Tags: patch Control: block -1 by 928035 On top of #928035, there is another change in gcc-9 that makes the gcc-9 patches no longer apply. The attached patch resolves the relevant hunk. Please consider uploading a new version that works with the current gcc-9. Helmut --- a/gcc-9/0004-added-multi-arch-specific-install-location-patch.patch +++ b/gcc-9/0004-added-multi-arch-specific-install-location-patch.patch @@ -368,9 +388,9 @@ + else +debian_patches += cross-install-location + endif - endif - - ifeq ($(DEB_TARGET_ARCH_OS),hurd) + ifeq ($(with_m2),yes) + debian_patches += cross-install-location-gm2 + endif -- 2.17.1
Bug#932762: fakeroot file somefile: Bad system call
Package: file Version: 1:5.37-3 Severity: serious Control: affects -1 + src:unbound file no longer works under fakeroot. For example: $ fakeroot file /bin/true Bad system call $ echo $? 159 $ This is relevant when packages that still require root for building use fakeroot and then call file. autoconf tends to use file and such use breaks cross building unbound for mips64el as it detects LD="ld -m elf" instead of LD="ld -m elf64smip". I suspect that this is also what breaks building binutils and causes the autopkgtest regression. Can we please disable seccomp until a solution for fakeroot is found? Helmut
Bug#928035: gcc-9 patches no longer applies
Package: cross-gcc-dev Version: 226 Severity: important Tags: patch User: helm...@debian.org Usertags: rebootstrap This bug is the second half of #925950. The bug was fixed for gcc-8, but not for gcc-9. Filing a new one at non-rc severity now. The fix is: sed -i -e 's/\(`TARGET\))/\1/' patches/gcc-9/*-now-depend-on-cpp-* Helmut
Bug#927230: cross-gcc-dev: gcc-9 patch application failure
Package: cross-gcc-dev Version: 230 Tags: patch bullseye sid Control: fixed 925950 230 When trying to apply the patched gcc-9 patches during a gcc-9 build, one gets a patch application failure during cross-ma-install-location.diff. It turns out that libmpx got removed in gcc-9, so it needs to be dropped from cross-ma-install-location.diff as well. The attached patch does just that. It also seems like the fixed version in #925950 is not properly recorded[1]. Using the opportunity to record the correct one. Helmut [1] Niels Thykier suggested that it was wrong when he closed the relevant unblock. One can use "fixed 925950 230" or "fixed 925950 cross-gcc/230", but "fixed 925950 cross-gcc-dev/230" does not work. You cannot fix something in a binary package. --- a/patches/gcc-9/0004-added-multi-arch-specific-install-location-patch.patch +++ b/patches/gcc-9/0004-added-multi-arch-specific-install-location-patch.patch @@ -16,7 +16,7 @@ index 000..7dd01d0 --- /dev/null +++ b/debian/patches/cross-ma-install-location.diff -@@ -0,0 +1,357 @@ +@@ -0,0 +1,337 @@ +Index: b/src/libada/configure.ac +=== +--- a/src/libada/configure.ac @@ -340,26 +340,6 @@ + toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)' + ;; + no) -+-if test -n "$with_cross_host" && -+- test x"$with_cross_host" != x"no"; then -+- # Install a library built with a cross compiler in tooldir, not libdir. -+- toolexecdir='$(exec_prefix)/$(target_alias)' -+- toolexeclibdir='$(toolexecdir)/lib' -+-else -+- toolexecdir='$(libdir)/gcc-lib/$(target_alias)' -+- toolexeclibdir='$(libdir)' -+-fi -++toolexecdir='$(libdir)/gcc-lib/$(target_alias)' -++toolexeclibdir='$(libdir)' -+ multi_os_directory=`$CC -print-multi-os-directory` -+ case $multi_os_directory in -+ .) ;; # Avoid trailing /. -+--- a/src/libmpx/configure.ac - b/src/libmpx/configure.ac -+@@ -70,15 +70,8 @@ -+ toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)' -+ ;; -+ no) +-if test -n "$with_cross_host" && +- test x"$with_cross_host" != x"no"; then +- # Install a library built with a cross compiler in tooldir, not libdir.
Bug#925950: patches no longer apply for gcc-8 and gcc-9
Control: fixed -1 cross-gcc-dev/230 Hi Dima, Great to see that you've already taken care. Much appreciated. On Fri, Mar 29, 2019 at 02:07:11PM -0700, Dima Kogan wrote: > My key situation should be resolved with the next keyring update, but > this will take a few weeks probably. If it's useful to you, you should > push the new package into the archive. I've worked around this locally now, so there is no urgency from my side. However, getting this into buster in a timely manner could be useful. If your key update takes longer, I can sponsor the upload. Helmut
Bug#925950: patches no longer apply for gcc-8 and gcc-9
Package: cross-gcc-dev Version: 226 Severity: serious Tags: patch The patches for gcc-8 and gcc-9 no longer apply to unstable. Around two weeks ago that used to work. Apparently, Matthias fixed a typo in debian/control.m4 and that happens to break the hunk context of one patch. The following sed expression fixes the patches: sed -i -e 's/\(`TARGET\))/\1/' patches/gcc-[89]/*-now-depend-on-cpp-* Helmut
Bug#918397: cross-gcc-dev should support gcc-9
Package: cross-gcc-dev Version: 217 Severity: important User: helm...@debian.org Usertags: rebootstrap Please rebase the patch series for gcc-9, which is available in experimental since today. Helmut
Bug#894745: cross-gcc-dev patches misapply for recent gcc-7 and gcc-8
Package: cross-gcc-dev Version: 184 Severity: important Tags: patch User: helm...@debian.org Usertags: rebootstrap The recent gcc-7 and gcc-8 uploads add a feature called FORCE_CROSS_LAYOUT. After these uploads, the cross-gcc-dev patches still apply, but they apply in a useless way. Part of their effect is moved from the cross compiler branch to the new FORCE_CROSS_LAYOUT branch and thus rendered ineffective. The attached patch fixes that. Helmut --- cross-gcc-184/debian/changelog +++ cross-gcc-184+nmu1/debian/changelog @@ -1,3 +1,10 @@ +cross-gcc (184+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Update for FORCE_CROSS_LAYOUT. (Closes: #-1) + + -- Helmut Grohne <hel...@subdivi.de> Tue, 03 Apr 2018 21:34:54 +0200 + cross-gcc (184) unstable; urgency=medium * rebuild for 8-20180331-1 --- cross-gcc-184/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch +++ cross-gcc-184+nmu1/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch @@ -83,11 +83,18 @@ index caa8b5e..e9eaf0f 100644 --- a/debian/rules.defs +++ b/debian/rules.defs -@@ -209,6 +209,9 @@ else +@@ -209,10 +209,16 @@ else # cross compiler, sets WITH_SYSROOT on it's own DEB_CROSS = yes build_type = build-cross +ifeq ($(with_deps_on_target_arch_pkgs),yes) ++ with_sysroot = / ++endif + else ifeq ($(FORCE_CROSS_LAYOUT),yes) + # a native build with a cross layout + DEB_CROSS = yes + build_type = build-cross ++ifeq ($(with_deps_on_target_arch_pkgs),yes) + with_sysroot = / +endif else --- cross-gcc-184/patches/gcc-8/0005-setting-all-the-various-paths-options-for-with_deps_.patch +++ cross-gcc-184+nmu1/patches/gcc-8/0005-setting-all-the-various-paths-options-for-with_deps_.patch @@ -83,11 +83,18 @@ index c63af56..3690f1b 100644 --- a/debian/rules.defs +++ b/debian/rules.defs -@@ -209,6 +209,9 @@ else +@@ -209,10 +209,16 @@ else # cross compiler, sets WITH_SYSROOT on it's own DEB_CROSS = yes build_type = build-cross +ifeq ($(with_deps_on_target_arch_pkgs),yes) ++ with_sysroot = / ++endif + else ifeq ($(FORCE_CROSS_LAYOUT),yes) + # a native build with a cross layout + DEB_CROSS = yes + build_type = build-cross ++ifeq ($(with_deps_on_target_arch_pkgs),yes) + with_sysroot = / +endif else
Bug#884051: cross-gcc-dev needs an update for the gcc-8 cilkrts removal
Source: cross-gcc Version: 163 Tags: patch User: helm...@debian.org Usertags: rebootstrap cilkrts got removed from gcc-8, so cross-ma-install-location.diff needs to stop patching it. Helmut --- 0004-added-multi-arch-specific-install-location-patch.patch +++ 0004-added-multi-arch-specific-install-location-patch.patch @@ -16,7 +16,7 @@ index 000..97117d6 --- /dev/null +++ b/debian/patches/cross-ma-install-location.diff -@@ -0,0 +1,379 @@ +@@ -0,0 +1,357 @@ +Index: b/src/libada/configure.ac +=== +--- a/src/libada/configure.ac @@ -340,28 +340,6 @@ + toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)' + ;; + no) -+-if test -n "$with_cross_host" && -+- test x"$with_cross_host" != x"no"; then -+- # Install a library built with a cross compiler in tooldir, not libdir. -+- toolexecdir='$(exec_prefix)/$(target_alias)' -+- toolexeclibdir='$(toolexecdir)/lib' -+-else -+- toolexecdir='$(libdir)/gcc-lib/$(target_alias)' -+- toolexeclibdir='$(libdir)' -+-fi -++toolexecdir='$(libdir)/gcc-lib/$(target_alias)' -++toolexeclibdir='$(libdir)' -+ multi_os_directory=`$CC -print-multi-os-directory` -+ case $multi_os_directory in -+ .) ;; # Avoid trailing /. -+Index: b/src/libcilkrts/configure.ac -+=== -+--- a/src/libcilkrts/configure.ac - b/src/libcilkrts/configure.ac -+@@ -103,15 +103,8 @@ -+ toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)' -+ ;; -+ no) +-if test -n "$with_cross_host" && +- test x"$with_cross_host" != x"no"; then +- # Install a library built with a cross compiler in tooldir, not libdir.
Bug#880917: cross-gcc-dev: gcc-8/0008-g-include-directories-functional-again.patch: broken patch
Package: cross-gcc-dev Version: 154 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Dima and Wookey, thanks for maintaining cross-gcc-dev. I noticed while the present gcc-8 patches do apply against gcc-8, they end up breaking g++-multiarch-incdir.diff. gcc-8/0008-g-include-directories-functional-again.patch has two hunks. The first of the modifies a hunk header of g++-multiarch-incdir.diff. That modification turns g++-multiarch-incdir.diff into a broken patch. The first hunk should be removed. The following command nullifies it: sed -i -e '/^+@@ -223,7 +235,45 @@/s/45/16/' patches/gcc-8/0008-g-include-directories-functional-again.patch After doing so, I can bootstrap gcc-8 for some architectures. Helmut
Bug#879774: cross-gcc-dev patches no longer apply to gcc-7 nor gcc-8
Package: cross-gcc-dev Version: 149 Severity: serious The patches no longer apply to gcc-7 nor gcc-8. Most likely this is due to the Priority change. Please rebase. Helmut
Bug#878356: cross-gcc-dev should support gcc-8
Package: cross-gcc-dev Severity: important User: helm...@debian.org Usertags: rebootstrap Please add support for gcc-8. That can have multiple forms, each of which has its own benefit: a) Just copy the gcc-7 patches to gcc-8 and hope for the best. b) Make the patches apply to the gcc-8 source package. c) Verify that a cross compiler can be built. a) has close to zero effort, b) likely takes an hour or so and c) longer. If you can do b), that'd be very useful already, but even a) helps. I'm happy to file followup bug reports with patches. The earlier we start, the less work we'll have. Go go. Helmut
Bug#783731: patch application fails for gcc-5
Package: cross-gcc-dev Version: 17 Tags: patch User: helm...@debian.org Usertags: rebootstrap Patch application fails with gcc-5. The attached patch fixes that. No provisions are made as to whether the resulting source tree can be built. Helmut diff -Nru cross-gcc-17/debian/changelog cross-gcc-17+nmu1/debian/changelog --- cross-gcc-17/debian/changelog 2015-04-26 05:17:35.0 +0200 +++ cross-gcc-17+nmu1/debian/changelog 2015-04-29 16:58:26.0 +0200 @@ -1,3 +1,10 @@ +cross-gcc (17+nmu1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Fix patch application for gcc-5. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Wed, 29 Apr 2015 16:58:16 +0200 + cross-gcc (17) experimental; urgency=medium * rules.generic now specifies bash as the SHELL (Closes: #780583) diff -Nru cross-gcc-17/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch cross-gcc-17+nmu1/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch --- cross-gcc-17/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch 2015-04-26 02:54:06.0 +0200 +++ cross-gcc-17+nmu1/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch 2015-04-29 16:58:03.0 +0200 @@ -511,9 +511,9 @@ --- a/debian/rules.defs +++ b/debian/rules.defs @@ -177,6 +177,9 @@ else - ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_TARGET_GNU_TYPE)) # cross compiler, sets WITH_SYSROOT on it's own DEB_CROSS = yes + build_type = build-cross +ifeq ($(with_deps_on_target_arch_pkgs),yes) + with_sysroot = / +endif
Bug#782071: gcc-5 patches no longer apply at all
Package: cross-gcc-dev Version: 13 Tags: patch User: helm...@debian.org Usertags: rebootstrap The gcc-5 patch set no longer applies at all. The cxx_inc_dir make variable was removed entirely, thus hunk that changes it no longer applies. It can simply be dropped. Helmut diff -Nru cross-gcc-13/debian/changelog cross-gcc-13+nmu1/debian/changelog --- cross-gcc-13/debian/changelog 2015-01-28 07:18:12.0 +0100 +++ cross-gcc-13+nmu1/debian/changelog 2015-04-07 13:12:26.0 +0200 @@ -1,3 +1,10 @@ +cross-gcc (13+nmu1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Fix gcc-5 patches to apply against 5-20150404. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Tue, 07 Apr 2015 13:11:36 +0200 + cross-gcc (13) unstable; urgency=medium * Supporting multiple gcc trees at the same time. Currently 4.9 and 5 diff -Nru cross-gcc-13/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch cross-gcc-13+nmu1/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch --- cross-gcc-13/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch 2015-01-28 07:18:12.0 +0100 +++ cross-gcc-13+nmu1/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch 2015-04-07 13:11:17.0 +0200 @@ -712,19 +712,6 @@ endif else usr_lib = $(PFL)/$(libdir) -@@ -921,7 +942,11 @@ ifneq ($(DEB_CROSS),yes) - cxx_inc_dir = $(PF)/include/c++/$(GCC_VERSION) - endif - else -- cxx_inc_dir = $(PF)/$(TARGET_ALIAS)/include/c++/$(GCC_VERSION) -+ ifeq ($(with_deps_on_target_arch_pkgs),yes) -+cxx_inc_dir = $(PF)/include/c++/$(BASE_VERSION) -+ else -+cxx_inc_dir = $(PF)/$(TARGET_ALIAS)/include/c++/$(GCC_VERSION) -+ endif - endif - - # FIXME: MULTIARCH_DIRNAME needed for g++-multiarch-incdir.diff @@ -1750,8 +1775,13 @@ ifneq ($(DEB_CROSS),yes) p_lgcc = libgcc$(GCC_SONAME) else
Bug#776509: building gcc-5 cross toolchains fails at applying cross-ma-install-location.diff
Package: cross-gcc-dev
Version: 13
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Steps to reproduce:
$ apt-get source gcc-5
...
$ cd gcc-5-*
$ QUILT_PATCHES=/usr/share/cross-gcc/patches/gcc-5 quilt push -a
...
$ echo arm64 debian/target
$ ./debian/rules patch
...
The last step fails at applying cross-ma-install-location.diff. The
attached patch updates src:cross-gcc to update the patch that adds
cross-ma-install-location.diff to the gcc source (i.e. it is a diff of a
diff of a diff %-). All that changed (in the innermost diff) is hunk
context.
Helmut
diff -Nru cross-gcc-13/debian/changelog cross-gcc-13+nmu1/debian/changelog
--- cross-gcc-13/debian/changelog
+++ cross-gcc-13+nmu1/debian/changelog
@@ -1,3 +1,10 @@
+cross-gcc (13+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix cross-ma-install-location.diff for gcc-5. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Wed, 28 Jan 2015 21:26:38 +
+
cross-gcc (13) unstable; urgency=medium
* Supporting multiple gcc trees at the same time. Currently 4.9 and 5
diff -Nru
cross-gcc-13/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch
cross-gcc-13+nmu1/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch
---
cross-gcc-13/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch
+++
cross-gcc-13+nmu1/patches/gcc-5/0004-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch
@@ -171,7 +171,7 @@
+-fi
++nover_glibgo_toolexecdir='${libdir}/gcc/${host_alias}'
++nover_glibgo_toolexeclibdir='${libdir}'
-+ multi_os_directory=`$CC -print-multi-os-directory`
++ multi_os_directory=`$GOC -print-multi-os-directory`
+ case $multi_os_directory in
+ .) ;; # Avoid trailing /.
+Index: b/src/libgomp/configure.ac
Re: Bug#774719: missing Build-Depends: gcc-4.9-base
clone 774719 -1 reassign -1 src:gcc-cross-support retitle -1 dependencies on cross-gcc-defaults must be versioned thanks On Wed, Jan 07, 2015 at 06:30:41PM +, Wookey wrote: But I see that the actual point here (which you didn't make clear above) is that currently it fails if gcc-4.9-base is not installed because it uses it to derive the current version number of gcc. I'll try to be more explicit next time. Thanks for seeking clarification. gcc-4.9-base is not actually essential, it's build-essential, which I presume is what you meant. gcc-4.9-base is actually pseudo-essential in sid as essential packages (transitively) depend on it. I'm not convinced that we should add a build-dep on a build-essential thing, just to make sure that it will fail marginally faster on a suite for which it is not available. The best reason for listing such build-deps is to help bootstrapping, and this one is MA:same, so maybe that makes sense? You do mean MA:foreign, no? Thats only useful if a new cross-gcc-defaults is uploaded (or a binnmu requested) everytime a new cross-gcc-ver-arch is uploaded (and this does mean that the version number match up for users so they don't get confused what version of the compiler is installed). But gcc-native is not doing this: apt-cache show g++ 4:4.9.2-1 apt-cache show g++-4.9 4.9.2-10 And neither are we currently. It would probably be easy to arrange to binnmu this for every new cross-toolchain upload and make sure they _do_ match up. Arguably, it may be useful if these version bumps are done occasionally and on request (i.e. if a major gcc bug is fixed). Having this bumping semi-automatically may help or may not depending on the color of your bike shed. If the versioned-cross-compiler and cross-compiler package version numbers don't match up then maybe the unversionned (gcc-triplet) packages should just use the source version, and stop pretending to match. If we did that then the build-dep on gcc-x.y-base would go away. Please don't. We have quite a number of packages that currently Build-Depends: gcc (= ...) (and surprisingly many forget the epoch ;-). Assuming that we will use the gcc-cross-support approach for translating build-depends, this will become Build-Depends: gcc-for-host (= ...). Thus gcc-for-host must use the same versioning as gcc. It can only do so if it can pass on version constraints to cross-gcc-defaults. Note: gcc-cross-support currently gets this wrong. It doesn't have a versioned dep, but needs to do so. Bug added above. Similarly the Depends: = 'build time gcc base ver' isn't useful so far as I can see. It should either be a fixed value that changes when there is some actual change in the package sets provided - e.g. front-ends added/removed, or architectures added/removed. (I think this is what the native gcc-defaults package is doing.) But of course that does require someone to remember to update it. We should certainly do something that is close to what the native gcc-defaults does as this works in the native case. Possibly the easiest way to do so is picking the value from gcc rather than gcc-X.Y-base. Or there shouldn't be a versionned dep at all. After all this is just a link. Any available, installable, cross-toolchain package will satisfy and work, so I'm not convinced that we need anything more explicit. Can anyone come up with reasons why that won't work? If it isn't versioned, it'll break lots of Build-Depends (after cross translation). The longer-term plan is (was?) for this package to merge into the main gcc-defaults so maybe it's not worth worrying about much. Seems reasonable. Also for cross-gcc-support. So, for now I propose not to add the build-dep, and not to change the version-number logic, and try the binNMU-on-upload idea. If that's not a faff then I think it'll be nicest for users. What do you think about using the version of the gcc binary package instead? It should update less often and is good enough for the native case. Helmut -- To UNSUBSCRIBE, email to debian-toolchain-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150107192059.gb16...@alf.mars
Bug#774719: missing Build-Depends: gcc-4.9-base
Package: src:cross-gcc-defaults Version: 0.4 User: helm...@debian.org Usertags: rebootstrap While gcc-4.9-base is essential in unstable and jessie, it is unavailable in wheezy. Therefore it would be good to mark cross-gcc-defaults as not being buildable there by Build-Depending on gcc-4.9-base. Helmut -- To UNSUBSCRIBE, email to debian-toolchain-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150106191926.ga13...@alf.mars
Bug#774739: triplet-gcc-ar missing in package gcc-triplet
Package: src:cross-gcc-defaults Version: 0.4 Tags: patch User: helm...@debian.org Usertags: rebootstrap The regular src:gcc-defaults package adds a gcc-ar - gcc-ar-X.Y symlink to the gcc binary package. At least the python2.7 build expects a triplet prefixed version of this link, but it is not found in the gcc-triplet packages. I am proposing the attached patch to address this issue. Helmut diff -Nru cross-gcc-defaults-0.4/debian/changelog cross-gcc-defaults-0.4+nmu1/debian/changelog --- cross-gcc-defaults-0.4/debian/changelog 2014-11-04 06:19:52.0 +0100 +++ cross-gcc-defaults-0.4+nmu1/debian/changelog2015-01-06 20:15:13.0 +0100 @@ -1,3 +1,10 @@ +cross-gcc-defaults (0.4+nmu1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Add a gcc-ar symlink to the gcc-* packages. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Tue, 06 Jan 2015 20:14:55 +0100 + cross-gcc-defaults (0.4) unstable; urgency=low * Added gobjc and gccgo to the default set of cross-toolchains built diff -Nru cross-gcc-defaults-0.4/debian/defaults cross-gcc-defaults-0.4+nmu1/debian/defaults --- cross-gcc-defaults-0.4/debian/defaults 2014-11-04 06:18:13.0 +0100 +++ cross-gcc-defaults-0.4+nmu1/debian/defaults 2015-01-06 20:13:17.0 +0100 @@ -1,6 +1,7 @@ -cpp 4.9 -gcc 4.9 -g++ 4.9 -gfortran 4.9 -gobjc 4.9 -gccgo 4.9 \ No newline at end of file +cpp cpp 4.9 +gcc gcc 4.9 +gcc gcc-ar 4.9 +g++ g++ 4.9 +gfortran gfortran 4.9 +gobjc gobjc 4.9 +gccgo gccgo 4.9 diff -Nru cross-gcc-defaults-0.4/debian/rules cross-gcc-defaults-0.4+nmu1/debian/rules --- cross-gcc-defaults-0.4/debian/rules 2014-11-21 20:10:49.0 +0100 +++ cross-gcc-defaults-0.4+nmu1/debian/rules2015-01-06 20:14:41.0 +0100 @@ -38,8 +38,8 @@ override_dh_auto_install: for arch in $(ARCHES_GNU_TYPE); do \ - while read prog ver; do \ - dh_link -p$$prog-$$arch usr/bin/$$arch-$$prog-$$ver usr/bin/$$arch-$$prog; \ + while read pkg prog ver; do \ + dh_link -p$$pkg-$$arch usr/bin/$$arch-$$prog-$$ver usr/bin/$$arch-$$prog; \ done debian/defaults; \ done
Bug#774356: stage2 powerpc multilib wdotap build fails
Package: cross-gcc-dev Version: 11 User: helm...@debian.org Usertags: rebootstrap A wdotap stage2 cross build from amd64 targeting powerpc with multilib fails. The tail of the log[1] is: | : # ppc 64bit build slaps libgcc and libstdc++ to powerpc64-linux-gnu | mkdir -p debian/tmp/usr/powerpc-linux-gnu/lib64 | cp -a debian/tmp/usr/powerpc64-linux-gnu/lib64/* debian/tmp/usr/powerpc-linux-gnu/lib64/ | cp: cannot stat 'debian/tmp/usr/powerpc64-linux-gnu/lib64/*': No such file or directory | debian/rules2:2060: recipe for target 'stamps/07-install-stamp' failed | make[1]: *** [stamps/07-install-stamp] Error 1 | make[1]: Leaving directory '/tmp/buildd/gcc2/gcc-4.9-4.9.2' | debian/rules:80: recipe for target 'stamps/07-install-stamp' failed The remainder of the build log tells that this is the first mention of powerpc64-linux-gnu/lib64. Instead the files mentioned are installed in the intended location (where they would be copied to). So I attempted a build with the same configuration except for disabling wdotap (i.e. using the supported method) and indeed the supported method does not fail here. This is why I am filing the bug against cross-gcc-dev. The relevant code can be found in gcc-4.9's debian/rules2[2] (search for slaps). It is conditional to: * DEB_CROSS = yes * multilib = yes * DEB_STAGE != stage1 * DEB_TARGET_ARCH = powerpc * biarch64 = yes Likely, this should also become conditional to with_deps_on_target_arch_pkgs != yes. The interesting bit here is that there is similar fix above this fix for DEB_TARGET_ARCH=s390. It is not clear whether it should also be disabled for wdotap. In particular, this cannot be tested, because glibc no longer builds for s390, so we cannot satisfy Build-Depends. What do you think? Opportunistically disable both or just the one we know to be unneeded for wdotap? (Based on this description either patch should be trivial.) Helmut [1] https://jenkins.debian.net/job/rebootstrap_powerpc_gcc49/96/console [2] http://sources.debian.net/src/gcc-4.9/4.9.2-10/debian/rules2/#L2184 -- To UNSUBSCRIBE, email to debian-toolchain-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150101133615.ga28...@alf.mars
