Bug#804190: please support cross compiler builds without relying on binutils-multiarch
Control: tags -1 - patch Control: tags -1 + moreinfo On 11.08.2018 18:18, Helmut Grohne wrote: > I didn't encounter a single binary package that ships both host and > target objects. Whenever they do, we can simply split the packages. at least gccgo-8- is such a package. Please also check for other frontends, not only the ones you use for the bootstrap. I'm not planning to work myself on splitting out a libgo-8-dev.
Processed: Re: Bug#804190: please support cross compiler builds without relying on binutils-multiarch
Processing control commands: > tags -1 - patch Bug #804190 [src:gcc-8] please support cross compiler builds without relying on binutils-multiarch Removed tag(s) patch. > tags -1 + moreinfo Bug #804190 [src:gcc-8] please support cross compiler builds without relying on binutils-multiarch Added tag(s) moreinfo. -- 804190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#804190: please support cross compiler builds without relying on binutils-multiarch
Processing control commands: > reassign -1 src:gcc-8 Bug #804190 [src:gcc-5] please support cross compiler builds without relying on binutils-multiarch Bug reassigned from package 'src:gcc-5' to 'src:gcc-8'. No longer marked as found in versions gcc-5/5.2.1-22. Ignoring request to alter fixed versions of bug #804190 to the same values previously set > tags -1 + patch Bug #804190 [src:gcc-8] please support cross compiler builds without relying on binutils-multiarch Added tag(s) patch. -- 804190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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
Processed: Re: Bug#804190: please support cross compiler builds without relying on binutils-multiarch
Processing control commands: > tags -1 - patch Bug #804190 [src:gcc-5] please support cross compiler builds without relying on binutils-multiarch Removed tag(s) patch. -- 804190: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#804190: please support cross compiler builds without relying on binutils-multiarch
Control: tags -1 - patch On Fri, Nov 13, 2015 at 12:20:14AM +0100, Matthias Klose wrote: > - the patch is incomplete. It still calls the binutils tools >for the host unprefixed. Can you give an example here? If you mean that some dh_strip calls are not prefixed, then that's intentional. See below for why. > - the patch doesn't work for cross building cross compilers >with host != target. Can you go into more detail here? My attempts at cross building gcc always fail earlier, so I cannot test that yet. > - maybe make it clear which tools are used (target_strip, host_strip >instead of cross_strip). I did consider that but deemed it inconsistent with the rest of the packaging. We already have cross_shlibdeps, cross_gencontrol, and cross_makeshlibs. Calling it cross_strip was the obvious continuation. So cross_strip could be renamed to target_strip in principle, but we do not need host_strip at all, because using the host architecture is the default. That's also why some of the dh_strip invocations do not need to be prefixed. Is there anything wrong with this approach? > 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 believe that there is no reason to support multiple architectures in a single binary package in dh_strip. At this point we have no single user of such functionality and debhelper is supposed to cover the common case. Given these questions (yours and mine), I think that the patch should not target the -24 upload, but receive more testing with the pending packaging changes. Helmut
Bug#804190: please support cross compiler builds without relying on binutils-multiarch
On 05.11.2015 22:50, Helmut Grohne wrote: Source: gcc-5 Version: 5.2.1-22 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, It would be nice if gcc supported cross compiler builds without relying on binutils multiarch. When bootstrapping new architectures it may be the case that the new architecture is not yet covered by binutils-multiarch. Furthermore it seems odd that the cross compiler builds would require both cross binutils and binutils-multiarch. In practise, the only reason why gcc needs binutils-multiarch is because dh_strip invokes binutils without a target triplet prefix. Other than that binutils-multiarch is not used at all. So I am proposing the attached patch that tells all relevant dh_strip invocations about the target triplet such that it works with cross binutils. Do you agree with the reasoning and the patch? - please update the patch to apply to the current VCS - the patch is incomplete. It still calls the binutils tools for the host unprefixed. - the patch doesn't work for cross building cross compilers with host != target. - maybe make it clear which tools are used (target_strip, host_strip instead of cross_strip). 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. Matthias
Bug#804190: please support cross compiler builds without relying on binutils-multiarch
Source: gcc-5 Version: 5.2.1-22 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, It would be nice if gcc supported cross compiler builds without relying on binutils multiarch. When bootstrapping new architectures it may be the case that the new architecture is not yet covered by binutils-multiarch. Furthermore it seems odd that the cross compiler builds would require both cross binutils and binutils-multiarch. In practise, the only reason why gcc needs binutils-multiarch is because dh_strip invokes binutils without a target triplet prefix. Other than that binutils-multiarch is not used at all. So I am proposing the attached patch that tells all relevant dh_strip invocations about the target triplet such that it works with cross binutils. Do you agree with the reasoning and the patch? Helmut diff -u gcc-5-5.2.1/debian/changelog gcc-5-5.2.1/debian/changelog --- gcc-5-5.2.1/debian/changelog +++ gcc-5-5.2.1/debian/changelog @@ -1,3 +1,11 @@ +gcc-5 (5.2.1-22.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Support building cross compilers for architectures not covered by +binutils-multiarch. Closes: #-1. + + -- Helmut GrohneThu, 15 Oct 2015 23:56:53 +0200 + gcc-5 (5.2.1-22) unstable; urgency=medium * Update to SVN 20151010 (r228681, 5.2.1) from the gcc-5-branch. diff -u gcc-5-5.2.1/debian/rules.d/binary-ada.mk gcc-5-5.2.1/debian/rules.d/binary-ada.mk --- gcc-5-5.2.1/debian/rules.d/binary-ada.mk +++ gcc-5-5.2.1/debian/rules.d/binary-ada.mk @@ -126,7 +126,7 @@ $(d_lgnat)/usr/share/lintian/overrides/$(p_lgnat) endif - dh_strip -p$(p_lgnat) --dbg-package=$(p_lgnat_dbg) + $(cross_strip) dh_strip -p$(p_lgnat) --dbg-package=$(p_lgnat_dbg) dh_compress -p$(p_lgnat) dh_fixperms -p$(p_lgnat) $(cross_shlibdeps) dh_shlibdeps -p$(p_lgnat) \ @@ -174,7 +174,7 @@ $(usr_lib)/libgnatvsn.so.$(GNAT_VERSION) \ $(usr_lib)/libgnatvsn.so debian/dh_doclink -p$(p_lgnatvsn_dev) $(p_glbase) - dh_strip -p$(p_lgnatvsn_dev) -X.a --keep-debug + $(cross_strip) dh_strip -p$(p_lgnatvsn_dev) -X.a --keep-debug dh_fixperms -p$(p_lgnatvsn_dev) $(cross_gencontrol) dh_gencontrol -p$(p_lgnatvsn_dev) \ -- -v$(DEB_VERSION) $(common_substvars) @@ -190,7 +190,7 @@ endif $(dh_compat2) dh_movefiles -p$(p_lgnatvsn) $(usr_lib)/libgnatvsn.so.$(GNAT_VERSION) debian/dh_doclink -p$(p_lgnatvsn) $(p_glbase) - dh_strip -p$(p_lgnatvsn) --dbg-package=$(p_lgnatvsn_dbg) + $(cross_strip) dh_strip -p$(p_lgnatvsn) --dbg-package=$(p_lgnatvsn_dbg) $(cross_makeshlibs) dh_makeshlibs -p$(p_lgnatvsn) \ -V '$(p_lgnatvsn) (>= $(DEB_VERSION))' $(call cross_mangle_shlibs,$(p_lgnatvsn)) @@ -239,7 +239,7 @@ dh_link -p$(p_lgnatprj_dev) \ $(usr_lib)/libgnatprj.so.$(GNAT_VERSION) \ $(usr_lib)/libgnatprj.so - dh_strip -p$(p_lgnatprj_dev) -X.a --keep-debug + $(cross_strip) dh_strip -p$(p_lgnatprj_dev) -X.a --keep-debug debian/dh_doclink -p$(p_lgnatprj_dev) $(p_glbase) dh_fixperms -p$(p_lgnatprj_dev) $(cross_gencontrol) dh_gencontrol -p$(p_lgnatprj_dev) \ @@ -256,7 +256,7 @@ endif $(dh_compat2) dh_movefiles -p$(p_lgnatprj) $(usr_lib)/libgnatprj.so.$(GNAT_VERSION) debian/dh_doclink -p$(p_lgnatprj) $(p_glbase) - dh_strip -p$(p_lgnatprj) --dbg-package=$(p_lgnatprj_dbg) + $(cross_strip) dh_strip -p$(p_lgnatprj) --dbg-package=$(p_lgnatprj_dbg) dh_fixperms -p$(p_lgnatprj) $(cross_makeshlibs) dh_makeshlibs -p$(p_lgnatprj) \ -V '$(p_lgnatprj) (>= $(DEB_VERSION))' @@ -398,7 +398,7 @@ debian/dh_rmemptydirs -p$(p_gnat) - dh_strip -p$(p_gnat) + $(cross_strip) dh_strip -p$(p_gnat) dh_compress -p$(p_gnat) dh_fixperms -p$(p_gnat) find $(d_gnat) -name '*.ali' | xargs chmod 444 @@ -412,7 +412,7 @@ dh_builddeb -p$(p_gnat) ifeq ($(with_gnatsjlj),yes) - dh_strip -p$(p_gnatsjlj) + $(cross_strip) dh_strip -p$(p_gnatsjlj) dh_compress -p$(p_gnatsjlj) dh_fixperms -p$(p_gnatsjlj) find $(d_gnatsjlj) -name '*.ali' | xargs chmod 444 diff -u gcc-5-5.2.1/debian/rules.d/binary-fortran.mk gcc-5-5.2.1/debian/rules.d/binary-fortran.mk --- gcc-5-5.2.1/debian/rules.d/binary-fortran.mk +++ gcc-5-5.2.1/debian/rules.d/binary-fortran.mk @@ -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) + $(cross_strip) dh_strip -p$(p_l) --dbg-package=$(p_d) dh_compress -p$(p_l) -p$(p_d) dh_fixperms -p$(p_l) -p$(p_d) $(cross_makeshlibs) dh_makeshlibs -p$(p_l) @@ -137,7 +137,7 @@ debian/dh_doclink -p$(p_l) $(p_lbase) debian/dh_rmemptydirs -p$(p_l) - dh_strip -p$(p_l) +