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

Bug#766708: Request to override gcc maintainer changes breaking unsupported way of cross-building

Matthias contended that the default method to build a gcc cross compiler
works with multiarch:

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

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.


Reply to: