Debian Bug report logs - #437422
RFP: crosstool-ng -- A versatile (cross-)toolchain generator

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

Date: Sun, 12 Aug 2007 13:21:03 UTC

Severity: wishlist

Done: David Moreno Garza <damog@merkel.debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, <wnpp@debian.org>:
Bug#437422; Package wnpp. Full text and rfc822 format available.

Acknowledgement sent to "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>:
New Bug report received and forwarded. Copy sent to <wnpp@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: RFP: crosstool-NG -- A versatile (cross-)toolchain generator
Date: Sun, 12 Aug 2007 15:18:40 +0200
Package: wnpp
Severity: wishlist

* Package name    : crosstool-NG
  Version         : 0.2.2
  Upstream Author : Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
* URL             : http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool
* License         : GPLv2
  Programming Lang: Shell script, Makefile
  Description     : A versatile (cross-)toolchain generator

crosstool-NG is a versatile toolchain generator, aiming at being highly
configurable. crosstool-NG supports multiple target architectures, different
components (glibc/uClibc...) and versions.

crosstool-NG also features debugging utilities (DUMA, strace...) and
generation tools (sstrip...).

Note: I'm the upstream maintainer (and main developper) of crosstool-NG, but
my time is quite limited and am afraid I won't be able to allocate enough
time to maintain the Debian packaging of crosstool-NG. Nonetheless, I'm
ready to spend enough time in the initial packaging, and on upstream
maintenance wrt Debian problems.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21.5-kemper (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash




Changed Bug title to `RFP: crosstool-ng -- A versatile (cross-)toolchain generator' from `RFP: crosstool-NG -- A versatile (cross-)toolchain generator'. Request was from Thomas Huriaux <thomas.huriaux@gmail.com> to control@bugs.debian.org. (Wed, 15 Aug 2007 09:06:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, <wnpp@debian.org>:
Bug#437422; Package wnpp. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to <wnpp@debian.org>. Full text and rfc822 format available.

Message #12 received at 437422@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 437422@bugs.debian.org
Cc: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Subject: Using Debian sources
Date: Wed, 5 Sep 2007 13:30:35 +0100
[Message part 1 (text/plain, inline)]
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.

Your website only mentions gcc-4.1 but Emdebian is currently updating to
build 4.2. 

http://www.emdebian.org/

You are welcome to discuss toolchain-stuff on the debian-embedded
mailing list or #emdebian IRC channel - details on the website.

Another problem is that your website doesn't provide access to the SVN
without checking out the sources locally so I can't look at the code.
Would it be possible to install websvn or something similar so that
interested visitors can take a look at the actual code?

The Emdebian script that prepares our toolchains is visible at:
http://buildd.emdebian.org/svn/browser/current/emdebian/trunk/buildcross/trunk
and is currently being rewritten by Hector Oron (zumbi).

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, <wnpp@debian.org>:
Bug#437422; Package wnpp. Full text and rfc822 format available.

Acknowledgement sent to "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>:
Extra info received and forwarded to list. Copy sent to <wnpp@debian.org>. Full text and rfc822 format available.

Message #17 received at 437422@bugs.debian.org (full text, mbox):

From: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To: debian-embedded@lists.debian.org
Cc: 437422@bugs.debian.org, Neil Williams <codehelp@debian.org>
Subject: Re: Using Debian sources
Date: Thu, 13 Sep 2007 20:12:17 +0200
Hello Neil!

Thanks for your feedback!

(For the records on the ML: this is discussion about bug 437422:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437422 )

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.

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. With crosstool-NG,
one can build a toolchain dedicated to its target machine, and use it to build
the software to run on it. 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). 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.


- 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.

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.


- Regarding what you call a "reverse cross":

crosstool-NG calls it "canadian cross" and is not yet functional. I'm working
on it, but this not the main interest of crosstool-NG right now, for the
reason explained above: targeted audience are those that want a toolchain to
cross-build software for their target, not necessarily those who want a
toolchain to run _on_ their target. But yet, I do know the need is there, as
I might soon have that need myself :-)

> Your website only mentions gcc-4.1 but Emdebian is currently updating to
> build 4.2. 

Ah yes. The latest gcc was being used by most sample configurations, but the
table was not up-to-date. It now is. Thanks for pointing out the lag. :-)

On the other hand, this table is but an example of what is possible and that
I have tested. crosstool-NG does propose the latest versions, as well as some
older ones (under the OBSOLETE option), and even experimental versions (under
the EXPERIMENTAL option).

> http://www.emdebian.org/

Been there! Thanks for the pointer, I'll look more closely at what's going on
there.

> You are welcome to discuss toolchain-stuff on the debian-embedded
> mailing list or #emdebian IRC channel - details on the website.

ML in CC:.

> Another problem is that your website doesn't provide access to the SVN
> without checking out the sources locally so I can't look at the code.
> Would it be possible to install websvn or something similar so that
> interested visitors can take a look at the actual code?

In fact, the repository in browseable on-line already: the scheme used to
access the SVN repository is http, so you can at least browse the HEAD.
But as you suggested, I did install websvn, which is accessible from the
project page. Thanks for the hint!

> The Emdebian script that prepares our toolchains is visible at:
> http://buildd.emdebian.org/svn/browser/current/emdebian/trunk/buildcross/trunk
> and is currently being rewritten by Hector Oron (zumbi).

I'll have a look, thank you!

Again, Neil, thank you for your feedback!

Regards,
Yann E. MORIN.

PS. I'm not sure wether I should keep the bug report CC:ed, so feel free to
    drop this CC: on subsequent replies.
YEM.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
°------------------------------°-------°------------------°--------------------°





Information forwarded to debian-bugs-dist@lists.debian.org, <wnpp@debian.org>:
Bug#437422; Package wnpp. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to <wnpp@debian.org>. Full text and rfc822 format available.

Message #22 received at 437422@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Cc: debian-embedded@lists.debian.org, 437422@bugs.debian.org
Subject: Re: RFP: crosstools-NG
Date: Thu, 13 Sep 2007 20:45:49 +0100
[Message part 1 (text/plain, inline)]
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/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, <wnpp@debian.org>:
Bug#437422; Package wnpp. Full text and rfc822 format available.

Acknowledgement sent to "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>:
Extra info received and forwarded to list. Copy sent to <wnpp@debian.org>. Full text and rfc822 format available.

Message #27 received at 437422@bugs.debian.org (full text, mbox):

From: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To: debian-embedded@lists.debian.org
Cc: Neil Williams <codehelp@debian.org>, 437422@bugs.debian.org
Subject: Re: RFP: crosstools-NG
Date: Fri, 14 Sep 2007 00:27:18 +0200
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 sent to David Moreno Garza <damog@merkel.debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #32 received at 437422-done@bugs.debian.org (full text, mbox):

From: David Moreno Garza <damog@merkel.debian.org>
To: 437422-done@bugs.debian.org
Subject: WNPP bug closing
Date: Tue, 16 Sep 2008 11:59:33 -0600
Hello,

This is an automatic mail sent to close the RFP you have reported or 
are involved with.

Your RFP wnpp bug is being closed because of the following reasons:
- It is, as of today, older than 365 days.
- It hasn't had any activity recently.

As this is an automatic procedure, it could of course have something
wrong and probably it would be closing some bugs that are not 
intended by owners and submitters (like you) to be closed, for
example if the RFP is still of your interest, or there has been 
some kind of activity around it. In that case, please reopen the
bug, do it, DO IT NOW! (I don't want to be blamed because of
mass closing and not let people know that they can easily reopen
their bugs ;-).

To re-open it, you simply have to mail control@bugs.debian.org
with a body text like this:

 reopen 437422
 stop

Further comments on the work done in the bug sent to
437422@bugs.debian.org would be truly welcomed.
Anyway, if you have any kind of problems when dealing with
the BTS, feel free to contact me and I'd be more than happy to help
you on this: <damog@debian.org>.

A similar process is being applied to other kind of wnpp bugs.

Thanks for your cooperation,

 -- David Moreno Garza <damog@debian.org>.
 




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 15 Oct 2008 07:28:56 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 03:11:29 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.