On Thu, 13 Sep 2007 20:12:17 +0200
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> wrote:
>
> (For the records on the ML: this is discussion about bug 437422:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437422 )
437422 is an RFP bug - Request for package. Yann has requested that
this package is added to Debian but, as upstream, is unable to maintain
it himself, even through a sponsor. I saw the RFP and wanted to find
out if there was a way around some of the problems inherent in this
request. I'm *not* proposing to maintain crosstools-NG myself.
> On Wednesday 05 September 2007 14:30, you wrote:
> > Building toolchains from the upstream sources for installation on
> > Debian would appear to be asking for problems. Emdebian is building
> > toolchains for cross-building using the Debian packages so that the
> > toolchain should be more easily installable alongside the native
> > toolchain. This also means that patches that may be needed for
> > generating a cross-building toolchain can be committed upstream. This
> > has also helped make gcc-4.2 build a "reverse cross" - where build !=
> > host, host == target as opposed to the usual cross build of build ==
> > host, host != target in order to provide libraries for installation
> > alongside the packages built with the toolchain.
> > So I'm not sure about crosstool-ng - I'm not sure where it would fit.
>
> Interesting evaluation. But let me make my points, if you will:
>
> - Regarding the build tools for Debian and its derivatives:
>
> From the beginning, I was *not* regarding crosstool-NG as a replacement for
> the build environement to build Debian and its derivatives.
No, I know that - but the Emdebian toolchains do aspire to building a
derivative or port of Debian. I'm still not sure that crosstool-NG
would fit into Debian.
> crosstool-NG aims at being a convenient way of building toolchains, most
> notably to embedded developpers, but also for all kind of projects. The
> targeted system need not be running a Debian derivative.
Which is where the conflict with the rest of Debian may arise. A
package trying to build toolchains is not like an ordinary application.
If the user expects the built toolchain to be installable on Debian,
there will have to be Debian-specific patches to the toolchain packages
and the build tool which just ends up duplicating what the gcc Debian
maintainers have already done and what Zumbi has done here. (Zumbi =
Hector Oron who prepares the Emdebian toolchains.)
> With crosstool-NG,
> one can build a toolchain dedicated to its target machine, and use it to build
> the software to run on it.
To do that, the toolchain packages have to be installable alongside the
rest of the Debian system AND the toolchain must be completely
transparent when trying to build native packages AND it needs to use or
be available to normal Debian build tools like pbuilder, dpkg and apt.
Emdebian toolchains do all that and they produce cross-built packages
that are valid .deb packages so that the binaries can be installed
using Debian tools on the embedded device itself. This allows
auto-building and updates in a way that other methods find difficult.
Even with all the support and work put in so far, keeping those
toolchains installable and updated with each update of gcc in Debian
is a hard job.
crosstools-NG is closer to how OpenEmbedded prepare their packages and
throwing away the patches that Debian has already implemented does seem
to be reinventing the wheel.
> Many projects, such as PDAs, routers,NASes and
> other mebedded stuff may not have enough storage capability to hold a Debian
> distribution (as is said on emdebian, most have a few Mebibytes of flash and
> not much more RAM).
I think you're preaching to the converted on that score.
:-)
Emdebian has a rootfs of 5Mb download, 15Mb installed and Simon Richter
and others are working on uclibc that will drop that much, much further.
We don't really see any practical limit - anything down to "a MMU-less
thing with a few MB of RAM and flash".
Don't be misled by the size of "normal" Debian. Emdebian has put Debian
on a dramatic diet.
:-)
I fully intend to improve on the GPE installation on my iPAQ that has
64Mb space and leaves only 7Mb free after a complete GUI installation.
> So projects targetting these devices need to be able to
> build specific toolchains, and carefully configured software, more often than
> not with a dedicated and "home"-made build system.
That is what Emdebian is trying to change - to create tools that build
an embedded distribution for any embedded device. Making such bespoke
methods redundant. We have the custom toolchains, we have carefully
configured software that is rebuilt using our own tools to strip out
and optimise the dependencies. It's just that Emdebian hasn't (IMHO)
thrown the baby out with the bath water by ditching the build system at
the same time as the undoubted bloat.
What is the point of a slow-moving bespoke installation that is hard to
update compared to a ready distribution of binaries that are updated
automatically? Emdebian isn't there yet but that is the direction.
Debian for embedded devices - all the benefits of a binary distribution
with rolling updates and user-friendly tools and none of the tedium of
rebuilding your own packages or toolchains.
> - Regarding pushing patches upstream:
>
> I don't have the time to push patches upstream (because I do that at home,
> not at work). So I just 'vampirise' patches here and there, mostly from the
> buildroot and the original crosstool. Some I did write myself.
That's really bad news. By using the Debian sources, Emdebian has a
ready collection of patches and a team of maintainers who are able to
improve and implement our patches both in Debian and upstream. i.e.
Debian has the resources and the time that you lack.
You seem to be making work for yourself and that can only slow down
development of the tool itself.
This alone makes me concerned that crosstool-NG would not be a good
addition to Debian. You could easily end up reimplementing patches that
Debian has already implemented upstream.
> Getting patches from the Debian packages seemed difficult to me as not all
> patches are applied for all architectures (the gcc package has patches that
> gets applied when targetting x86_64 but not when targetting MIPS, for
> example). Unless I was mistaken... And I want the toolchains to be all built
> with the same code base.
That may end up not playing to the strengths of amd64 or compromising
performance on mips.
Yes, the gcc build system in Debian is a frightening place - I spent
more than enough time hacking at it during DebConf7, as Wookey will
testify! It managed to get me *seriously* annoyed and that's very rare
nowadays.
> - Regarding what you call a "reverse cross":
>
> crosstool-NG calls it "canadian cross" and is not yet functional.
No, reverse cross is different to canadian cross.
> e.g.
> Build=amd64|i386|powerpc
> Host=arm
> Target=arm
>
> compared to
> build=amd64|i386|powerpc
> host=amd64|i386|powerpc
> target=arm
> for a standard cross-compiler.
http://www.mail-archive.com/debian-embedded@lists.debian.org/msg02589.html
In effect, reverse cross is used when you need to cross-build
{a package that happens to be} a compiler instead of build a
cross-compiler. (Read that carefully.)
A Canadian cross is:
Build=amd64|i386|powerpc
Host=arm
Target=mips
We don't yet support that. I'm not sure if it's necessary.
> reason explained above: targeted audience are those that want a toolchain to
> cross-build software for their target,
That is what reverse cross achieves - to get certain libraries from the
gcc source such that they will run on arm. Treating gcc-4.2 sources as
"just another source package" that needs to be cross-built - the only
difference is that you first have to use the same source to build the
cross-compiler.
Doesn't embedded terminology drive you round the twist??!!
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpjoTamfBXpq.pgp
Description: PGP signature