[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