[uClibc]Some notes on the toolchain builder

Jay Carlson nop at nop.com
Mon Sep 9 11:36:52 UTC 2002


I'm reworking the uclibc toolchain builder for the mips snow ABI.  Here 
are some disconnected notes.  Please don't be offended at tone.  This 
is just a slightly more civil version of the notes file I wrote for 
myself, and putting together "make world" scripts is always a finicky 
business, able to make anybody cranky.  :-)  Also, previous versions of 
my snow toolchain builder are out there---my particular glass house is 
filled with baskets of decorative and convenient rocks....

I strongly prefer separate source and build directories, when the 
package supports it.  gcc is built that way; binutils should be too.  
Ultimately, it would be nice if uclibc could be built that way, of 
course....

It would be nice if sources weren't touched after their initial setup.  
Mostly, this means I think the ldso hacks target in the phase 2 gcc 
build should move up into the patched phase.

Never ever write "cd foo; do_something" as a make rule.  If foo somehow 
doesn't exist, you end up spraying the effects of do_something all over 
your Makefile's directory.  Write "cd foo && do_something" instead.  (I 
learned that one the hard way....)

As a generalization, script fragments should detect failure.  Use "set 
-e" to make errors halt execution.  You can still make the whole 
fragment ignore failure with the leading -.  Most of the uclibc build 
proper does this.

The parens around (cd foo && do_something) aren't needed, as each 
fragment runs in a separate shell already.  The parens can be useful as 
documentation, however.

I found I had to specify RANLIB_FOR_TARGET (and AR_FOR_TARGET) as a 
make argument (not an environment variable) to build gcc 3.2; otherwise 
the wrong one got picked.  I find it rather annoying that gcc will test 
for its existence with [ -f $RANLIB ] rather than using runability.  
That means you really do have to pass in an absolute path (as the 
toolchain builder does.)  I'm not sure why it has to be a make argument 
now.

The way the uclibc install_dev rule is invoked over and over again 
disturbs me somehow.

I forget.  Why are we fighting the crt0 vs crt1 battle anyway?

Is the uclibc-gcc wrapper useful at all for cross?

Jay




More information about the uClibc mailing list