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 <firstname.lastname@example.org> To: Ian Campbell <email@example.com> Cc: Matthias Klose <firstname.lastname@example.org>, Adam Conrad <email@example.com>, Adam Conrad <firstname.lastname@example.org> 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= g00004.html 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. > > Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/