[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

+++ Helmut Grohne [2014-10-28 07:13 +0100]:
> 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.
> > 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.

Whilst it is 'default' in the sense that it's what you get if you
don't set any variables, I contend that (in Debian, but not Ubuntu) it
is not the default build. In fact the 'default' build has not worked
(in debian) for at least a year, probably two. I have tried and failed
to make it work this year (ran out of time - clearly it is possible).

However the 'non-default' 'with_deps_on_target_arch_pkgs' build has
been working for at least a year, and is in fact the build that
everyone using cross-toolchains in Debian testing or unstable has been
using for some time. It is also the one that is better documented. And
now it is the one that is used in the packages recently uploaded to
the archive. To me that sounds like this method is actually the
current de-facto default in Debian - it is certainly at least on a par. 

The with_deps_on_target_arch_pkgs was developed as a 2012 GSOC
project.  It was done because cross-compiler builds _do_ depend on
foreign-arch libraries, and setting the build up to just use the ones
already natively built in the archive (where they exist) is simple and
(IMHO) correct. This simplicity is why it has been very easy to use
and keep working. Those libraries come from the linux, libc and gcc

The alternative, which is used in the 'default' build, involves either
taking those existing native-built library binaries and repackaging
them (using dpkg-cross) in 'classic' (pre-multiarch) cross-compiler
locations, or rebuilding them (as a cross-build) as part of the build
and putting them in those locations.

The net result is a second copy of the libraries, shipped with the
cross-compiler. And, especially in the case of the full
'toolchain-base' build, the process is complicated and fragile. The
build builds linux to get linux-libc-dev-cross, libc to get libc6-dev,
and then gcc. But in fact to do that it actually builds linux,
binutils, gcc (stage1), libc (stage1), gcc (stage2), libc (stage2),
gcc (stage3). This process does work, as is demonstrated by the use of
these packages in Ubuntu for some time, but it is undeniably much more
complicated than just building against already-built libraries. I am
not sure whether recent changes to libc packaging have made this
process simpler - I need to check current status there.

Note that the simpler with_deps_on_target_arch_pkgs build is only
useful where the foreign-arch packages are already built, which makes
it seem like the 'toolchain-base' method must be used for
bootstrapping. However Helmut's rebootstrap has demonstrated that the
with_deps_on_target_arch_pkgs method is useful there too. I must admit
that I have not fully grokked how this works as I had thought that
this was the one case where it didn't work.

> > Are the maintainers of the disputed features subscribed to the
> > appropriate packages in the PTS ? 

I am subscribed to the binutils and gcc packages in the PTS, yes, and
have been for a while, mostly to track uploads in order to keep the
cross-binutils and cross-gcc packages in sync.

> > 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.

Certainly. As I am currently using it for my cross-toolchain packages
I am keen to see it kept working, at least until an alternative works
and is demonstrably better/as good.
> > 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-*.)

There is a set of source packages (uploaded as one per target arch,
for manageability reasons, but actually all coming from the same git
tree) that builds cross-compilers from gcc-source. These builds
currently use the with_deps_on_target_arch_pkgs because a) it works 
and b) it's cleaner and simpler.

I was very disapointed when the outcome of uploading these (just) in
time to get into Jessie (maybe), was disablement of the functionality
in the gcc sources, and 'grave' bugs filed, specifically to stop them
migrating. Whilst there is clearly room for improvement, I don't think
this was an appropriate reaction.

Mattias has always said he doesn't want to be responsible for
maintaining the cross-toolchains, which is fine, I am prepared to do
that, but that also means he shouldn't get a veto on _how_ they are
maintained. Obviously if he was maintaining them himself he could
upload what he likes. 

> I am not opposed to disabled with_deps_on_target_arch_pkgs
> in general, 

I am. It's simple and reliable and (at least IMHO) more correct. There
are tradeoffs between the two methods which I'm happy to continue to
discuss and work on, but I want it kept around and working (and will
help do that) until either consensus is reached amongst the
gcc/cross-gcc/rebootstrap maintainers, or we decide that that's simply
not possible.

> [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.

It has been discussed many times, since agreement in priciple to do
this at Banka Luka. It was a release goal (insofar as we had any of those) 

An upload to experimental would not have given any possibility of
getting into Jessie, for which we know there is demand. I do agree it
would have been much better to do it with more time before the freeze
deadline, but I had other tasks too, and it just took time.
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

Reply to: