On 29 October 2014 06:32, Helmut Grohne <hel...@subdivi.de> wrote: > Matthias contended that the default method to build a gcc cross compiler > works with multiarch: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708#73 > > On Sun, Oct 26, 2014 at 03:50:59PM +0100, Helmut Grohne wrote: >> Why is with_deps_on_target_arch_pkgs needed? >> >> Without this flag, gcc emits dependencies on libc*-$arch-cross. In order >> to satisfy these dependencies binary packages from glibc have to be >> repacked and renamed. When using the resulting cross toolchain to build >> further Debian packages there are two choices, both of which are bad: >> * Newly cross built packages also depend on libc6-$arch-cross. This >> will make them different from natively built packages and in >> particular makes debootstrap fail. >> * Newly cross built packages keep their dependency on libc6. This will >> make them uninstallable in the build chroot, because there is no >> foreign arch libc package that can be co-installed with the >> aforementioned libc*-$arch-cross. >> Either option makes the bootstrap of a new architecture fail. > > I do not immediately see where this rationale is flawed, but I cannot > reproduce his claim: When building with the default method, the > resulting packages are uninstallable, because libc6-$arch-cross is not > available in the archive and not built from any source package. Thus the > default method relies on out-of-archive code whereas the > unsupported with_deps_on_target_arch_pkgs method does not. It looks like > this issue should be addressed in a package different from gcc, but to > date this hasn't happened. > > So it may be wise to ignore the quoted reasoning (on the grounds that it > cannot be verified), because the code that makes it work has not yet > arrived. > > This actually was the primary reason for me to start using > with_deps_on_target_arch_pkgs when learning about cross compilation: I > couldn't figure out where to obtain these libc*-$arch-cross packages, > but when I just set that flag I wouldn't have to. I therefore argue that > getting the relevant support into the glibc package could be a > resolution of the complaint made to the ctte, but now we're stepping on > entirely different toes. (Again this seems to be a timing thing, as > Matthias and Adam Conrad are apparently working on this.) > >> Why is DEB_CROSS_NO_BIARCH needed? >> >> There currently is a bug in rebootstrap that makes building multilib >> enabled cross-toolchains fail. Thus far I failed to figure out the >> reasons for this failure (beyond knowing that gcc looks for crti.o in >> the wrong directory). So in the spirit of having something working >> rather than nothing, this fiddle is needed to bootstrap multilib-enabled >> architectures now. I intend to eliminate the need DEB_CROSS_NO_BIARCH. > > Note that this need might be a consequence of using > with_deps_on_target_arch_pkgs=yes and might be unneeded with the > supported default method. >
Following this bug report loosely I'm failing to see why any changes, or proposed patches are needed to the src:gcc-4.x packages. The libc*-$arch-cross packages come from rebuilds of glibc package. All of which can be compiled trivially with Build-Depends / Build-Using: linux-source, gcc-4.x-source, glibc-source. An example of doing so one can check out out of the archive armhf-cross-toolchain-base / gcc-4.8-armhf-cross packages and similar for other architectures (arm64, ppc64el, etc.) The benefit of those are that they do not rely on multiarch repositories to be present on the builders, or the users installed systems (which by the way is not yet default in Debian anywhere), allow those toolchains to be migrated by britney independent of the multi-arch scew, and allow to be rebuild/moved to default versions independent of the src:gcc-4.x / src:binutils, apply any cross specific patches, and be multilib. Current gcc packaging is complex, and it should move towards simplification that is zero base budget (remove/reduce amount of packaging code, must not increase LOC or bolt on more features). If supported cross-toolchains are desired to be in archive, they need to be stand-alone and not break when native toolchain is updated, therefore own (verified) cross-versions (rebuilds) of libc and gcc is a must. The proposed multiarched builds, are only good for one time out of the archive bootstraps, but in no way are supportable in the archive. I found it trivial to work with current cross-building support via toolcahin-base support package which leverages existing binutils/glibc/gcc cross-building support. To both perform regular cross toolchains to debian arches, and use a different libc (bionic). Instead of adding more patches to src:gcc, a stand-alone src packages should be used that build-depend on gcc-4.x-source/binutils-source/gcc-source etc. and thus independently maintained, and accumulate/deal with their own set of RC bugs, and would not block, nor be inter-locked, nor coupled with native default major release upgrades. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
