Bug#804190: please support cross compiler builds without relying on binutils-multiarch

2018-08-14 Thread Matthias Klose
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

2018-08-14 Thread Debian Bug Tracking System
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

2018-08-11 Thread Debian Bug Tracking System
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

2018-08-11 Thread Helmut Grohne
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

2015-11-14 Thread Debian Bug Tracking System
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

2015-11-14 Thread Helmut Grohne
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

2015-11-12 Thread Matthias Klose

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

2015-11-05 Thread Helmut Grohne
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 Grohne   Thu, 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)
+