A meeting tool place at Linaro Connect on 9th Feb 2015, with Matthias Klose/doko (gcc maintainer), Adam Conrad/infinity (glibc maintainer), Wookey (cross-gcc maintainer), and Ian Campbell (Referee/Witness/Scribe).

Ian mailed the notes, which were accepted with the below qualifications.

Date: Thu, 12 Feb 2015 07:39:38 +0000                                                                  
From: Wookey <wookey@wookware.org>                                                                     
To: Ian Campbell <ijc@debian.org>                                                                      
Cc: Matthias Klose <doko@debian.org>, Adam Conrad <adconrad@debian.org>, Adam Conrad                   
Subject: Re: Debian tech ctte issues 
+++ Ian Campbell [2015-02-11 10:34 +0000]:
> On Tue, 2015-02-10 at 09:02 +0100, Matthias Klose wrote:
> Here are the notes, please say if you don't agree with something,
> especially the CONCLUSIONS section at the top. I don't think I captured
> everything in the NOTES, but please do offer corrections.

I've commented on a couple of things. I think it's a reasonable
(albeit not entirely complete) record of what was said.

> ---- CONCLUSIONS ----
> cross-toolchain-base to use binutils-cross. Optional, not
> required. [Adam]
> Somebody to get kernel lack of debian dir in linux-source pkg
> fix. [Adam]
> cross-toolchain-base to move to VCS somewhere and be part of an Alioth
> group. [Doko to talk to Dmitri] [ALL to join pkg-cross]

Not sure what "pkg-cross" is here. Did we mean
https://alioth.debian.org/projects/crosstoolchain/? or some other
group? Everyone who cares about this is already a member that alioth
project except Doko. Will he join? (that would be helpful).

> Prove that cross-toolchain-base works for one architecture which has
> multilib. e.g. powerpc. [Adam]
> Make it work for all architectures. Produces libc-$ARCH-cross for all
> arches we care about. [Adam]
> Wookey's cross-gcc switched to depend on libc-cross instead of
> libc:$ARCH. Produces cross-gcc-X.Y-$ARCH.dsc which are uploaded one
> per architecture. [Wookey]
> Everyone agrees that cross-toolchain-base is halfway sane, solves
> Adam+Doko's complaints and doesn't annoy Wookey.

Well, doesn't annoy Wookey enough to refuse to work with its
results. :-) It does annoy me (or more accurately I'd prefer it not to
be part of normal cross-toolchains builds, only of bootstrapping). But
so long as the people who want it maintain it, I can work with that.

Are we going to put any timescale on the above? My only concern is
what happens if in a few more months time the toolchain-base and
kernel-source changes still aren't done/working?

Doko did say that he would (consider?) putting wdotap back into the
gcc packaging, but only _after_ cross-gcc-* packages using -cross were
uploaded. Which seems a tad perverse as we need to carry on using it
_until_ that is done, but probably not afterwards.

> ------- NOTES -------
> doko: cross-compiler targeting a Debian architecture should be
> equivalent and produce the same code as a native toolchain. Doesn't
> want the cross-compiler maintainers to apply other patches.

I'm happy with that, but (unless I misunderstood) Doko went further,
to insist that cross-compilers provide the same set of front-ends and
multilibs as native compilers, otherwise he wants to be able to veto
them in the archive.

I still don't think that's reasonable, but it becomes moot under our
proposed actions above.

> adam: makes zero difference at runtime but makes a difference to the
> packaging.
> the "internal" libc makes very little difference, only used if no
> other libc is installed.
> Wookey: Easier to package with multiarch
> Doko: Wants cross-compiler in Debian to be able to cross compile gcc
> itself
> Adam: Wrong to upload packages which cannot be built on a buildd.
> Wookey: This is fixed with the new sbuild (0.64.3 or later).
> Adam: Allowing cross-arch build-deps will lead to cowboying in the
> archive.
> Adam: Bigger thing is bootstrapping a new architecture, having a fully
> self-contained cross gcc is very useful.
> Wookey: Building with or without gcc is working in Jenkins now, gets
> stuck
> Doko: Isn't proven.
> Wookey: Can do it either way, is progressing. Missing libgcc issue.
'missing libgcc' issue is: https://lists.debian.org/debian-cross/2014/12/ms=
and we do still need to fix that somehow, because it applies in the
building with -cross case AIUI

> Doko: Two issues: Rebootstrap and providing the cross compiler. Helmut
> wants to have completely installable packages for the
> bootstrap. We/cross-toolchain package unpacks but doesn't install, to
> sidestep the issue.
> Adam: A self-contained XCC doesn't require a foreign arch
> libc:$ARCH. Need to have a foreign arch already built.
> Wookey: You just do a normal 3 stage bootstrap
> Adam: But dpkg needs to know about it, so you would rebuild dpkg.
> Doko: We build packages and mangle them, Helmut's rebootstrap takes an
> intermediate package, which is not quite correct.
> Doko: Not sure that gcc requires most attention currently, more
> problems with glibc cross building. binutils+gcc does cross building,
> but glibc needs either dpkg-cross or have it build directly from libc
> packaging.
> Wookey: multilib cross now works, so multilib is now independent from
> multiarch, how it should be. Makes template cross meta-source package
> more complex since it is no longer a simple substitution. Have to
> reproduce some of gcc's build system.
> Nobody wants to maintain a seaprate cross-$ARCH for each ARCH, should
> all be the same source, with templating etc etc.
> Wookey: We either need to use foreign build-deps on libc:$ARCH or some
> other thing to create libc-cross.
> Doko: Would object to an upload of gcc-cross-support package (a
> metapackage to allow gcc-for-host and gcc-for-build packages). Would
> like to see this maintained by gcc maintainers.
> Doko: Doesn't mind contributions to gcc, to be in gcc group. But
> doesn't see that, but none of the cross maintainers are currently
> involved. Would like to keep it that way. No problem with people who
> work with upstream or packaging.
> Adam: Metapackages step on toes of gcc-defaults, since cross-defaults
> should always match. So best if they are maintained under same umbrella.
> Wookey: We don't patch gcc, apart from to reintroduce the WDOTAP
> thing. Would you consider putting that back.
> Doko: Don't need them to build a stand alone cross compiler. It's
> incomplete (e.g. multilib).
> Adam/Wookey: This is now working.
> Doko: How do you handle ports which are not released?
> Wookey: We just use whatever libc is available.
> e.g. glibc on powerpc libc6:powerpc and libc6-ppc64:powerpc both built
> from same glibc build. Not pulling libc6:ppc64 from ports, since
> unless they are all from release architectures you run into sync
> issues. Allows multilib cross builds
> Adam: Another issue: linkers (/lib/ld-linuxFOO) are not unique so
> cannot always co-install. Which is annoying if you want to build a
> kernel. The standalone builds avoid this by putting them in another
> path.
> The build-dep turns into a rntime dep, on e.g. libc:$ARCH. Whereas
> libc-cross has moved the ld-linux out of the way.
> Adam: Cross people should join the gcc-maint team and commit to the
> git tree.
> Wookey: Shall we make libc-cross packages in glibc?
> Adam: As in the glibc build should work similar to the binutils and
> gcc cross targets. We should do this, but dpkg-cross works for now.
> Wookey: We will get there eventually, but today we don't have the bits
> and pieces.
> Adam: We would be happy to do the standalone cross compilers if there
> is a feeling that this approach.
> Wookey: If you upload that then I don't prefer it but I won't upload a
> competing set of compilers.
> Doko: Many of the patches for cross building broke standalone or
> native builds. Still some bugs in the gcc packaging from the merging
> of the old separate cross packaging.
> Wookey: Cross-toolchain-base could replace dpkg-cross for the
> non-foriegn arch glibc.
> 4 sources that cross-toolchain base deps on kernel, gcc, glibc,
> binutils. But could use exisintg binutils-cross package, which is in
> Jessie.
> Doko: Need to build hppa64 in binutils-cross, since it is needed for
> gcc-cross.
> Doko: As long as the patches are taken from the binutils-source.
> Everyone agrees that crosstool-base could just use the existing
> binutils cross binary packages.
> Wookey: kernel-source package misses debian dir, so cannot be used by
> cross-toolchain-base.
> Next steps:
> Step 1: Prove that cross-toolchain-base works for one
> architecture which has multilib. e.g. powerpc
> Step 2: Make it work for all archiectures. Produces libc-$ARCH-cross
> for all arches we care about.
> Step 3: Wookey's cross-gcc switched to depend on libc-cross
> instead of libc:$ARCH. Produces cross-gcc-X.Y-$ARCH.dsc which are
> uploaded one per architecture.
> Everyone is OK with multiple source packages per tgt arch for now.
> Doko: Do we need to be able to cross build cross compilers?
> (i.e. a Canadian cross build).
> Adam: Doesn't see any need for such things in the archive.
Principal hats:  Linaro, Debian, Wookware, ARM