On Thu, 13 Sep 2007 20:12:17 +0200 "Yann E. MORIN" <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]/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/
pgpaKxPuzontn.pgp
Description: PGP signature