+++ 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 packages. 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) https://wiki.debian.org/ReleaseGoals/CrossToolchains 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. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
