This is the mail archive of the mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [crosstool-NG] Design discussion

On Sunday 05 April 2009 14:15:56 Rob Landley wrote:
> > This post is to present the overall design of crosstool-NG, how and why
> > I came up with it, and to eventually serve as a base for an open discussion
> > on the matter.
> For comparison, my Firmware Linux project also makes cross compilers,

So, it boils down to comparing _your_ project with _mine_.
I am all for comparing, but I'm afraid we do not have the same goals.

You've argued against cross-compiling ore often than not, and you did make
good points at it. And, from what I understand, FWL is your proof of concept
that cross-compiling can be avoided.

And you proved it. Partially. But that's not the point.

Just my turn to rant a little bit ;-) For many, cross-compiling can't be
avoided. Running under an emulator is biased. Your ./configure might
detect some specifics of the machine it's running on (the emulator) that
might prove wrong on the real hardware, Or the other way around, miss
some specifics of the real hardware that the emulator does not provide.

So, we're stuck. Or are we?

( Just a side note before I go on. I do not use the same meanings as you
  do for the following words:
    build (machine) : the machine that _builds_ stuff
    host (machine)  : the machine that _runs_ stuff
    target (machine): the machine the stuff _generates_ code for

  For a compiler (binutils, gcc, gdb), the three make sense, but for other
  programs (glibc, bash, toybox...), only the first two do.

One of the problem I can see with FWL is how you end up with a firmware
image that runs on the target platform (say my WRT54GL ;-) ), and contains
only what is needed to run it, without all that native build environment
that will definitely not fit in the ~7MiB available in there.

My point of view is that:
1- you need correct build tools, of which a correctly isolated toolchain
2- you build your packages and installs them in a rootfs/ directory
   (rootfs/ will contain only your packages instaleld files, and is missing
    the toolchain libs)
3- you use a copy of rootfs/ which you populate with libs from the toolchain
4- you use that populated copy to build your firmware images

Of course, if your packages are not cross-compile friendly, you may have
problems. But nowadays, most common packages do cross-compile neatly. I
have seen only a few of them requiring carefully crafted ./configure options
or a few patches here and there (ltrace is such a sucker). 

For the records, I have some experience in that field as well ;-), as I've
been doing exactly this stuff for the past for years as my day-time job,
and I've played with LFS and cross-LFS for the previous three years or so.

Note: crosstool-NG was *not* written at mu day-time job, but on my own
spare time (which gave some frictions here at home from time to time...

> so I  
> have some experience here too.

And, I do acknowledge your experience and your technical merit.
You know it, let's others know it as well. :-)

> My project is carefully designed in layers so you don't have to use the cross 
> compilers I build.  It should be easy to use crosstool-ng output to build the 
> root filesystems and system images that the later scripts produce.  (How easy 
> it actually is, and whether there's any benefit in doing so, is something I 
> haven't really looked into yet.)  The point is the two projects are not 
> actually directly competing, or at least I don't think they are.

The main goals differ, but the underlying reason is the same: be able to
build stuff that will run on an alien machine. crosstool-NG is limited to
building the required tools (actual compiler, plus a few debug utilities),
while FWL aims at building a native build environment.

> I came at it from a different background.  I was playing with Linux From 
> Scratch almost from the beginning,

LFSer as well in the 2001-2004 era. Went as far as using it as my daily
workstation using KDE. Yeah, I was *that* insane at the time. But taught
me a whole lot in the end.

[--SNIP the genesis of FWL--]

> I looked at crosstool circa 2004-ish, but was turned off by the way it 
> replicated huge amounts of infrastructure for every single dot release of 
> every component.  (I remember it having separate patches, separate build 
> scripts, and so on.  I don't even remember what it did per-target.)

How can you avoid having one patchest for each version of each component?
Of course, FWL uses only the latest versions availabe (which is wrong, it
still uses gcc-4.1.2 for philosophical reasons) of a few set of packages
(namely: binutils, gcc, uClibc, linux for the toolchain, I don't care about
the other tools, which do not belong to the toolchain)

> I wanted something generic.  A single set of source code, a single set of 
> build scripts, with all the variations between them kept as small, simple, 
> and contained as possible.

Correct here.

> I actually ended up not basing anything off of crosstool.  Instead when Cross 
> Linux From Scratch came out, I learned from that, and by asking a lot of 
> questions of coworkers at an embedded company I worked at for a year 
> (Timesys).  But this was 2006, so it was after you'd already started with 
> this.

Which is not a reason why I should not review what I've done today, no more
it is that I should.

> Along the way I wrote this:

But, of all packages I've been using, most are *now* cross-compile friendly
(with some notable exceptions) and the ones that gave me the most headaches
where the ones coming from company who don't grok the terms "open" and "free
as in speech". *Those* were real suckers.

> >  a- ease overall maintenance
> >  b- ease configuration of the toolchain
> >  c- support newer versions of components
> >  d- add new features
> >  e- add alternatives where it was available
> Can't really argue with those goals, although mostly because they're a bit 
> vague.

What do you mean, "vague" (I understand the word, it's the same in french)?
The question is really: what in the above list qualifies as "vague"?

> My current build system has very careful boundaries.

Call it an API?

> This is not only because my first couple systems grew out of control 
> (adding more and more packages and more and more features), but because I 
> watched Erik's buildroot explode from a test harness for uClibc into an 
> accidental Linux distribution.

Don't speak buildroot with me. Please, just don't. ;-)
I totaly agree with you on the subject, let's close it.

> This is why my current system is very carefully delineated.  I know exactly 
> what it does NOT do.  It builds the smallest possible system capable of 
> rebuilding itself under itself.  I.E. it bootstraps a generic development 
> environment for a target, within which you can build natively.  It has to do 
> some cross compiling to do this, but once it's done you can _stop_ cross 
> compiling, and instead fire up qemu and build natively within that.

Except that it in fact does cross-compiling, as it is escaping the qemu
via distcc to call the cross tools on the build machine. :-/

> > So that was how crosstool-NG was born to the world...
> Yup.  And from that set of assumptions you've done a fairly good job.

Accepted, thank you! ;-)

> What  
> I'm mostly disagreeing with is your assumptions.

There are two things:
- the goal
- the assumptions made to reach that goal

Both make the "why". What I came up with makes the "how".

As for the goal, I wanted to be able to build dependable (cross-)toolchains.
On the assumptions, I saw that I could not rely on binutils/gcc/glibc/... to
build easily (which is quite the case), and that I need a kind of framework
to make them build seamlessly.

No we can discuss this, but the original discussion was not to see if the
"how" was the best way to answer the "why".

> In my case, I separated my design into layers, the four most interesting of 
> which are:
> - download all the source code and confirm sha1sums
> - create a cross compiler for a target.

crosstool-NG stops here. And strives at offering more options than your

A great many people are stuck with a specific version of any one or more
or the components (gcc/glibc/...) for historical reasons I am not ready
to discuss. Having a tool that can not cope with earlier versions is
not helpfull.

> - build a root filesystem containing a native toolchain
> - package the root filesystem into something qemu can boot

Those two _use_ the above, htey are not part of it.

> > The first step was to split up this script into smaller ones, each
> > dedicated to building a single component. This way, I hoped that it would
> > be easier to maintain each build procedure on its own.
> I wound up breaking the version into a 
> dozen or so different scripts.  My earlier versions the granularity was too 
> coarse, in that one the granularity got too fine.  I think my current one has 
> the granularity about right; each script does something interesting and 
> explainable.

So are each scripts in scripts/build/ : they are dedicated to building a
single piece of the toolchain, and each can be replaced without the others
noticing (or so it should be the case).

> Notice there is _nothing_ target-specific in there.  All the target 
> information is factored out into sources/targets.  The build scripts 
> _do_not_care_ what target you're building for.

That's the same in crosstool-NG: the configuration and the wrapper scripts
set up some variables that the build scripts rely upon to build their stuff.

The target specific configuration is generic, but can be overidden by
target-specofic code (eg. ARM can overide the target tupple to append
"eabi" to the tupple if EABi is enabled, and to not add it if not enabled;
this can *not* be done in a generic way, as not all architectures
behave the same in this respect).

> Ok, a few questions/comments that come to mind here:
> 1) Why do we have to install your source code?  The tarball we download from 
> your website _is_ source code, isn't it?  We already chose where to extract 
> it.  The normal order of operations is "./configure; make; make install".  
> With your stuff, you have to install it in a second location before you can 
> configure it.  Why?  What is this step for?

I don't understand. crosstool-NG is like any other package:
- it requires some pre-existing stuff in your environemnt, hence the
  "./configure" step
- you have to build it, hence the "make" step (although this is only
  sed-ing a few place-holders here and there)
- you have to install it to use it, hence the "make install" step
- you add its location/bin to the PATH

Then you can run ct-ng, from anywhere and you build your toolchain.
I mat repeat myself, but do you expect to build your own program in the
gcc source tree?

> 2) Your configuration menu is way too granular.  You ask your users whether or 
> not to use the gcc "-pipe" flag.  What difference does it make?  Why ask 
> this?  Is there a real benefit to bothering them with this, rather than just 
> picking one?

I will answer this in an answer to your other post, if you will.

> I want to do a more detailed critique here, but I had to reinstall my laptop a 
> couple weeks ago and my quick attempt to bring up your menuconfig only made 
> it this far:
> ./configure --prefix=/home/landley/cisco/crosstool-ng-1.3.2/walrus
> Computing version string... 1.3.2
> Checking for '/bin/bash'... /bin/bash
> Checking for 'make'... /usr/bin/make
> Checking for 'gcc'... /usr/bin/gcc
> Checking for 'gawk'... not found
> Bailing out...
> I note that Ubuntu defaults to having "awk" installed, why you _need_ the gnu 
> version of specifically is something I don't understand.

I could not make my awk script work with mawk, which is the default under
the obscur distribution I am using (Debian, I think). So I fallback to
installing gawk. But that was an *enourmous* error. Its main use it to try
to build a correct tsocks setup given the options. *That* is purely insane.
It should be going away. No, it /should/ not be going away. It *is* going

The fact that I shoehorned proxy settings in crosstool-NG is an error,
granted, but because I'm using GNU extensions in there, so I must check
for GNU awk.

> For example, you require libtool.  Why are you checking for libtool?

crosstool-NG itself does not require libtool. The components that it builds
will use it if they find it. But if the version is too old, the build will
break (I think it was mpfr at fault there, but am not sure), instead of
simply ignoring it.

So I have also to ensure a correct environment for the components I build.

> I note  
> that libtool exists to make non-elf systems work like ELF, I.E. it's a NOP on 
> Linux, so it's actually _better_ not to have it installed at all because 
> libtool often screws up cross compiling.

But what if it *is* already installed? The end-user is feree to install
whatever he/she wants on his/her computer, no? It's just that I want to
check that the environment is sane before going on any further.

The fact that libtool sucks is totaly irrelevant to the problem.
And yes, it sucks.

> (In my experience, when a project  
> is designed to do nothing and _fails_ to successfully do it, there's a fairly 
> high chance it was written by the FSF.  One of the things my 
> does is make sure libtool is _not_ in the $PATH, even when it's installed on 
> the host.

Oh, come-on... ;-) My libtool is in /usr/bin. Do you want to remove /usr/bin
from my PATH? You'll end-up missing a lot of stuff, in this case.

OK, so now moving on to answer your other post(s)... Took me about two hours
trying to answer this one... :-(

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  |
| | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

For unsubscribe information see

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]