Re: mig cross-toolchain
Hi Samuel,
On Fri, Jun 19, 2020 at 07:25:41PM +0200, Samuel Thibault wrote:
> We now have the cross-mig packages in the archive, and I have uploaded
> gnumach & hurd to build-depend mig-for-host instead of mig.
Thank you for working on this. When you talk about cross toolchains,
please Cc debian-cross@lists.debian.org. Doing so now.
> There are however two things that may pose problem:
>
> - mig-for-host:hurd-i386 is multi-arch: same and depends on
> mig-i686-gnu:
>
> Package: mig-for-host
> Source: mig
> Architecture: hurd-i386
> Depends: mig-i686-gnu
> Multi-Arch: same
> [...]
This part looks good to me.
> and mig-i686-gnu:amd64 doesn't have a multi-arch field
> (explictly removed in debian/rules, I don't remember why):
>
> Package: mig-i686-gnu
> Source: mig
> Architecture: amd64
> Depends: libc6 (>= 2.14), libfl2 (>= 2.5.33)
> [...]
>
> Don't we want to make mig-i686-gnu:amd64 multi-arch:foreign so
> that it can fill the dependency of mig-for-host and provide a
> /usr/bin/i686-gnu-mig that can actually be executed? When I keep it
> multi-arch:foreign things seem to be working fine.
In principle yes. Since the target architecture is part of the package
name and encoded in command names, we consider it not affecting the
interface. This aspect is expressed via Multi-Arch: foreign.
There is one major exception. Some tools (such as binutils) allow
loading of plugins (shared objects). I'm not aware of any such system in
mig, but for this reason, we cannot mark binutils-$triplet Multi-Arch:
foreign. It is Multi-Arch: allowed instead. When you don't use plugins,
you annotate the dependency :any. So please check for a plugin loading
system before adding Multi-Arch: foreign.
> - When I add_automatic mig, once the mig source package is cross-built
> automatically, the result (mig:hurd-i386 mig-for-host:hurd-i386
> mig-i686-gnu:hurd-i386) replaces completely the mig_1 build
> (mig-i686-gnu:amd64) which gets moved to archive/:
>
> ./archive/mig_1
> ./archive/mig_1/mig-i686-gnu_1.8+git20200618-2_amd64.deb
> ./pool/main/m/mig
> ./pool/main/m/mig/mig-for-host_1.8+git20200618-2_hurd-i386.deb
> ./pool/main/m/mig/mig_1.8+git20200618-2_hurd-i386.deb
> ./pool/main/m/mig/mig-i686-gnu_1.8+git20200618-2_hurd-i386.deb
>
> I guess it's the reboostrap automatic build that does not support
> merging with previous builds for another architecture?
Yes. This is a limitation of rebootstrap. It really is a hacky script
that barely gets stuff built, but is relatively stupid otherwise.
However, I think that this is irrelevant due to another issue. We need
mig-for-host quite early. At that point, we don't have glibc yet.
Therefore, we cannot build mig-i686-gnu yet. So we need some build
profile that allows building mig-for-host, but not mig-i686-gnu to
remove the (implicit) libc6-dev dependency.
I don't think we have a standard profile name for this. We'll need a
similar profile for binutils and gcc in the long run. I'm not sure
whether it makes sense to standardise the profile name for three
packages, so maybe use one from the per-package namespace.
Helmut
Reply to: