Re: libc6-*-cross, etc
+++ Marc Glisse [2015-06-13 10:50 +0200]:
> Hello,
>
> as a happy user of gcc-4.9-aarch64-linux-gnu (and several others), I
> was glad to notice the new gcc-5-aarch64-linux-gnu and decided to
> install it, but I was surprised to notice that it depends on many
> *-arm64-cross packages. I already have the regular multiarch :arm64
> version of those packages installed, and that was good enough for
> gcc-4.9-aarch64-linux-gnu.
>
> I tried to find an explanation for this change, I assume there are
> good reasons for it, but all I found was this email:
> https://lists.debian.org/debian-cross/2015/03/msg00001.html
> which tells me nothing about *why* this happened.
The gcc maintainer feels very strongly that it must be done this way.
> Could someone point me to the relevant discussion?
This page gives some insight:
https://wiki.debian.org/ToolChain/Cross/Roadmap
and refers to the Tech Ctte bugs on the subject which also give some
background.
A summary of the pros and cons of the two build methods is on this page:
https://wiki.debian.org/ToolChain/Cross
> Currently, it doesn't make sense to me. I am using multi-arch and
> qemu-user-binfmt to test software for various architectures with
> minimal hassle. libc6:arm64 will always be needed by the other
> dependencies I have (say libmpfr-dev:arm64 for instance) and I don't
> see why I should install a second copy in a strange location. The
> *-cross packages look like a step backwards, saying that multiarch
> was a bad idea that we should abandon; is that the case?
I agree with you, but the gcc maintainer doesn't.
> Would it be
> possible to present it as an alternative, so the *-cross packages
> are only installed for people who refuse to run 'dpkg
> --add-architecture' or for architectures that we cannot multiarch
> (ld.so conflict)?
You can build multiarch-dependency ('wdotap') toolchains using the
cross-gcc-dev package, which is maintaining the build mechanism
outside of gcc. We cannot currently upload both sort of compiler to
the archive as they produce the same binaries. Some renaming could
make that possible.
Your idea is an interesting possibility, and whilst the dependencies
could easily be alternatives, I'm not sure if the internal compiler
paths can easily made to do both flavours at once - currently it's a
build-time choice. I don't know if the gcc maintainer would consider
patches to do this?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: