Re: Cross tools comments
Hi,
On Fri, Dec 04, 2009 at 05:26:07PM +0100, hector.oron@gmail.com wrote:
> Let me explain, current way of building (lenny) depends on dpkg-cross
> which we want to remove from the archive (not sure when, after multiarch
> maybe).
Yes, after a full transition to multiarch. In principle, those libraries
required for the toolchain build are going to switch to multiarch before
squeeze.
An evil hack that might just work: As we cannot declare dependencies on
specific architecture packages, I'd suggest we create a metapackage:
Package: libc6-dev-armel-cross
Architecture: armel
Multi-Arch: foreign
Depends: libc6-dev
This package doesn't need to be updated as new libc6-dev packages come
out, as all it does is pull in the real package from the right
architecture. This does require multiarch capable apt and dpkg.
> So we need to bootstrap cross tools, which has been implemented at
> emdebian.org/git/buildcross.git. The only problem is to do the bootstrap
> eglibc and gcc have circular depends and they need several builds before
> they provide a useful binary.
We won't get rid of that too soon anyway; for the Debian archive, I
think it is acceptable to not bootstrap every time.
> There are two orthogonal options to build our unstable toolchain
> (multiarch or sysroot or sysroot+multiarch). Plus there are three
> diferent ways this could be implemented.
I'd treat sysroot as something that is only used by the end user, if
they want to point their cross gcc at a target installation using
CFLAGS. As this target installation could be a Debian like chroot which
uses multiarch, we need to support multiarch paths inside a sysroot, and
as people want to continue using stuff installed into /usr/$target,
those traditional paths need to be supported as well (which sysroot
doesn't).
> a) Cross tools as an output of main Debian source package (as
> lenny). Quite good when working with several arches (these share
> same code). Some native maintainers, as gcc/binutils would prefer
> not having cross builds output from its native package.
This would also require lots of coordination in the form of "could you
enable a foo targetted build", and generally won't scale well.
> b) Cross tools as an output of new source packages build depending on
> -source binaries. One source package per component
> (eglibc,binutils,gcc-X.Y,linux-libc-dev). Which makes lots of
> packages to maintain 4 or 5 (if we add gdb) per architecture and if
> we add uclibc and other non-official arches this list of packages
> could grown over a 100 source packages.
Sounds pretty sane, provided these source packages are not maintained by
hand. I think there could be a Very Short Shell Script(tm) that queries
apt-cache showsrc and generates the appropriate packages for upload to
Debian and emdebian autobuilders -- I think this will be the way to go
for architectures already bootstrapped.
> c) Cross tools as an output of one source package. Each target
> architecture would only have one source package containing all the
> components. This way makes it more practical than b) but it means we
> need to rebuild all the tools each time one component updates.
We *also* need this one, for bootstrapping, and probably generated by
the same script. The idea would be to generate the large package (which
would essentially only build one libc and the most recent gcc), give
that to the autobuilders in addition to the smaller meta packages above.
The only package that can be built at this point is the binutils builder
package, as the others are missing build dependencies; with binutils
built, we can build the "combined" metapackage, which enables building
the others. The binaries built from the combined package are then
replaced by the ones from the small packages, so the version of the
combined package needs to be smaller (easy to achieve by appending a
"~bootstrap" to the version number), and after the binaries are
replaced, the source vanishes from the archive as well. Due to an
interesting bug in NEW handling, this doesn't even require more action
from the ftpmasters.
> I would like to know if users have any comment on these issues. b) and
> c) makes us independent from native maintainers, so if fine with
> everybody I might start working on c).
With my proposal, c) is an extension to b).
Multiarch sort of prohibits c), as the bootstrapped libc would live in
an Archictecture: all package named as if it were a dpkg-cross converted
package, which is not what we want for target architectures that are
also in Debian. Building a "~bootstrap" version as a -foo-cross style
package and then replacing it with a metapackage as described above
would work though.
> About sysroot and multiarch, any comments? We might keep current
> layout for some time (without multiarch nor sysroot) as dpkg-cross
> does not support sysroot and multiarch is not ready yet.
There is no support dpkg-cross could have for sysroot; wishlist bugs for
multiarch exist for some time now, but I haven't found the time to make
it actually work.
Simon
Reply to: