Re: Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Mon, Oct 27, 2014 at 09:41:59PM +0000, Ian Jackson wrote:
> > The most obvious bug is the one mentioned in the patch: #760770
> > It is about a bug in the implementation of with_deps_on_target_arch (the
> > contended feature).
>
> I think I may not understand what's going on here. In your mail to
> the TC, you say:
>
> it was possible to build a gcc cross compiler with different
> properties from the default build by setting
> with_deps_on_target_arch_pkgs=yes and DEB_CROSS_NO_BIARCH=yes.
>
> You mean setting these as environment variables ? If so then it would
> seem that this feature has no direct effect on anyone who is not
> trying to use it. Is that correct ?
It is correct, that builds that do not set these variables are not
affected by it beyond also carrying it as dead code in the gcc
packaging.
> Of course it does have a maintenance burden on the package maintainer,
> which is what Don is asking about.
I have to admit that the code is not exactly lightweight. I do
understand the desire to get rid it and asked that a ctte ruling does
not apply beyond jessie for that reason.
> #760770 shows an element of that but it is immediately obvious from
> the initial report that something odd is going on and it contains a
> link to #720363 which mentions
Oh, my previous bug research has missed gcc-4.8 bugs.
> https://wiki.debian.org/MultiarchCrossToolchainBuild which talks
> abouit the with_deps_on_target_arch_pkgs feature. It doesn't appear
> that #760770 has taken a great deal of Matthias's time, although it
> did necessitate some bug triage.
One of the issues here is that the submitter wasn't explicit about using
the non-default build here. It only surfaced in message 19 and can be
spotted from looking at the patch. When being asked to do a
self-contained cross build (and the self-contained kinda implies not
using with_deps_on_target_arch_pkgs), a log with the alternative build
method is sent back.
> Are the maintainers of the disputed features subscribed to the
> appropriate packages in the PTS ? Does Matthias welcome help triaging
I am not subscribed yet. The major reason is that I did not perceive the
maintenance of the feature as a problem until Matthias stated it in this
bug. It is certainly fixable.
> these bugs ? It seems to me that it would be easy to come up with a
> workflow that allowed Matthias to usertag these kind of bugs and hand
> them over to the cross teams.
Sounds reasonable to me. Asking Wookey whether he would like to share
that work.
> What are the cross-gcc-4.9-armhf packages that are referred to ?
It is a source package that uses the gcc-4.9-source binary package from
the gcc-4.9 source package to build a cross compiler targeting armhf. In
GNU terminology that is build=host=amd64, target=armhf. The packaging is
thin compared to the gcc-4.9 packaging and its goal is to enable people
to just apt-get install cross toolchains rather than building them each
time they need them. (I am not a maintainer of cross-gcc-4.9-*.)
Judging from the replies, I would like to repeat the timing argument
here:
The mechanism being discussed was disabled in gcc-4.9 without any
advance notice or discussion[1]. The code for supporting the default
method in glibc has not yet arrived in the Debian glibc package or the
BTS, but Matthias indicated that he would be working on that and he
seems to make progress outside Debian. I am not opposed to using the
default build method for bootstrapping new Debian architectures in
principle, but in my experience it takes a long time to merge patches
into the glibc packaging and the freeze is certainly not accelerating
that process. I am not opposed to disabled with_deps_on_target_arch_pkgs
in general, just now is the wrong time, because it is impossible to get
the corresponding functionality to gcc's default cross build into glibc.
Most of the changes necessary to make the alternative method work with
glibc have been merged however: #743676 #754350 #756095 #742640 #745380
#752480 #755580 #756473 (but most of these changes are also necessary
for the default method)
Helmut
[1] It is worth noting here that the upload of cross-gcc-4.9-* similarly
lacked discussion. An advance notice to the gcc list or targeting
experimental would have been better here.
Reply to: