Re: RFP: crosstools-NG
Hello Neil!
All,
On Thursday 13 September 2007 21:45, Neil Williams wrote:
> 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.
From what I can read, I understand you are reluctant to add crosstool-NG to
Debian because you are afraid that the so build toolchains do not fit
the Emdebian way of working.
I'm afraid we don't target the same goals. While Emdebian aims at building an
embedded version of Debian, which in itself I can understand and approve,
crosstool-NG only proposes toolchains for those adventurous enough to try
and build their own Linux-From-Scratch-like distributions.
As I see it, crosstool-NG is but a way to achieve this goal. Not all devices
have to be running Debian (or Emdebian, for it matters). I find Debian a very
good and attractive workstation system (dev, doc, mail and the likes), but I
don't see Debian (or Emdebian) fit my daily needs for my embedded work.
What I'm telling is that working on Emdebian so that it can fit in the 4MiB
flash of my router, running with 4Mib RAM, there will be lots of work to do!
With a custom toolchain, a bit of hacking here and there, I'm able to setup
a system in less than a week. My NAS has seen my Linux system in less than
three days from the moment I started until it booted and served me files and
http. My PDA will need a bootloader prior to run Linux (Debian, Emdebian or
whatever else). I need a toolchain for that! My geode-based tablet PC has
seen Debian on it in less than a day, but I had to attach an IDE disk. It is
since running hapilly a custom-made system build in five days (nights in fact).
The embedded world is so vast, that one can't think of all that can be needed
in every cases. Some of those cases can well be covered with Emdebian. Some
with custom-made systems build using crosstool-NG toolchains. Some may even
fit neither.
crosstool-NG is yet another way of building 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.
Nah. I don't think we should restrict what the user wants to do. If he/she
does not want to run Debian on his/her target, why bother building deb tools?
Diversity! ;-)
> 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.
Nice, but some system can't afford a packaging system. I have a device where
each kebibyte I can save I do! The system is static, and if I need to upgrade
it, I download a whole new system onto it.
> 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.
I can understand that! ;-)
> 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.
Again, I'm not so sure. But you make one point: it would be smarter if the
patch set was common! Would save a lot of time!
> 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.
Below 4MiB (including bootloader, kernel, rootfs and a writeable partition)?
With what tools?
What target?
> We don't really see any practical limit - anything down to "a MMU-less
> thing with a few MB of RAM and flash".
Ambitious goal! If Embdebian succeeds to the point that virtually all system
can be installed a Debian on it, with enough tools so that the device does
the job it was designed for, then I will applause! But until then, there
should be a way to do the job.
> Don't be misled by the size of "normal" Debian. Emdebian has put Debian
> on a dramatic diet.
> :-)
I can see that!
> 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.
The goal on my PDA is to have the system below 8MiB, bootloader, kernel and
userland apps included, leaving about 56MiB for the data.
> 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.
Again, what if people don't want to install that distribution, but have
specific needs that require a custom-built toolchain, a home-made build
system, with target specific needs? I'm thinking of those that have
in-house patches for the components (gcc/ binutils) to support specific
features of a processor. And those are legions.
> 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.
Nah. I don't want an packaging system on some of my devices! Some don't
even have a screen and a input system, they are absolutley blind devices!
> > - Regarding pushing patches upstream:
> 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.
I know... But again, the patches from the sources packages for gcc really
/disgusted/ me out of using them... Sorry to say that, this is one point
I dislike of Debian... :-(
> That may end up not playing to the strengths of amd64 or compromising
> performance on mips.
So if a patch to gcc strengthens an architecture are weakens another,
then it is bad. At worst, the code shall be conditional.
Patches only touching MIPS files are not applied for the x86_64 case, and
vice-versa. This I can understand, because it virtually doesn't change the
resulting compilers.
But what I find odd, is that patches touching /core/ files get applied
conditionnaly on the architecture being targeted (or build on). This, IMHO,
is a sign that the patch does something nasty to the compiler... I don't
like it. I want the same code-base for all the compilers I write, should
they run on two different, un-related architectures, such as MIPS and
x86_64 are.
> 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.
If something does not come into place in my head in the first hours I look
at it, I throw it away. I can't afford to spend time at understanding such
a thing that looks so broken to me...
> No, reverse cross is different to canadian cross.
> http://www.mail-archive.com/debian-embedded@lists.debian.org/msg02589.html
Thanks for the pointer! :-)
> 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.)
Yeah, I understand. Reverse cross are build to provide a native toolchain
in the target, and, IMHO, are a simplified case of the canadian-cross.
> We don't yet support that. I'm not sure if it's necessary.
There are needs for canadian cross. I have two machines, one x86_64
workstation, fast, large memory, and a x86 notebook, not so fast, small
memory, but much more transportable than my WS! Building a toolchain on
the x86 takes ages, while my WS build them in minutes. And my notebook I
can take with me when on travel and on shows, and it is enough to build
small programs for my targets.
> Doesn't embedded terminology drive you round the twist??!!
I'm not sure I understand this sentence... But embedded world has been my
world for the past decade professionnaly and perssonnaly. Before that, I was
a student in a computer school and graduated /easily/. So I guess I know my
ways. Yes, embedded space is strange, and sometime is really twisted...
I guess it is better to stop arguing about crosstool-NG's inclusion in
Debian. I have a specific view on the subject, you've got yours. You get the
point because you have /ancestry/ over me. Which is OK for me :-)
I truly understand your concerns about crosstool-NG not integrating with
the other Debian build infrastructure. I understand the problem of patch
duplication you rose. I can see where Emdebian is aiming at.
If it comes that Emdebian tools get better than crosstool-NG (for the needs
I have), then I'll do the switch happily. Until then, I'll continue my work
on crosstool-NG, if at least for my personal use and education. Any one is
welcome to get it as of today.
Thank you for taking the time to investigate this RFP, and giving so thorough
explanations! :-)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< °_° >==-- °------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
°------------------------------°-------°------------------°--------------------°
Reply to: