[uClibc] Buildroot questions.
rob at landley.net
Thu Aug 7 19:42:20 UTC 2003
On Thursday 07 August 2003 03:06, tom at ceisystems.com wrote:
> I thank you on behalf of any newcomers to the BuildRoot system for your
> efforts on writing a HOWTO. I have a couple suggestions, a coule
> answers, and a couple observations...so lets get right to it.
You're welcome. Glad somebody's reading it.
The current state of buildroot is "it doesn't work very well", due to the fact
that half the code it downloads is from the free software foundation, and
apaprently they got cracked. alpha.fsf.org is down with a note saying the
server's been abducted by aliens orsomething, and half the packages on their
main ftp site have been replaced by little notes saying they've been removed
pending verification of their authenticity. When I tried to hack the build
to use the older versions I have lying around on my hard drive and fake up a
Linux From Scratch stage 1 build (I.E. "chapter 5") using the buildroot stuff
to cross-compile tools linked against uclibc, the gzip build overwrote my
system gzip! (My fault for doing it as root, I know...) Which of course
wouldn't run because my laptop is glibc based and it complained that the
uclibc elf loader wasn't there when it tried to execute...
Took most of an hour to undo that. Still don't know if I broke it or if it's
broken in buildroot...
> Remvoing the target list from the Makefile _could_ be a good idea, but
> will also add confusion to the system and make room for error.
It's there now. Right now the target list is in the middle of the makefile,
which means I'm having to explain "okay, skip past this bit, now edit this
bit, now don't edit anything after here".
If the config file approach is good, I'd start out by moving the current
default target list (including the commented out examples) straight into the
new default config file, and worry about any cleanups in a second pass later.
> simplest way I can think of is to parse a file which contains each of
> the targets you want. Sed can handle this pretty well, or (if you
> prefer) Perl will do as well. However, the more dependance you place on
> external utilities, the more chance there is that the utility will:
> A) Not exist
Sed is already required by the uclibc build, and it's it's part of busybox.
Embedded systems might not have it, but anywhere that has enough space to fit
gcc and binutils can probably be trusted to have sed.
Perl is huge, I'd rather live with the requirement to put "TARGETS+=blah" in
the config file than add a dependency on perl.
(I'd also been pondering awk, but I think we should just let awk rest in peace
at this point. Sed's a bit simplistic, but all we really want to do is chop
off # comments, split each word onto its own line (tab/space->newline), and
then prepent "TARGETS+=" to each non-blank line. That's what, three passes
in sed, at most?)
> B) Not conform to the standard you wish
Sed is mentioned by posix and the single unix specification.
> C) Fail its execution, and return a partial or garbled list
Fail due to garbled input, sure. That problem won't go away. Fail due to sed
being horked, your system has bigger problems than buildroot.
> D) Any, all or none of the above.
This adds no new information.
> This, of course, is just my opinion based on previous experiences...and
> may be completely off base. I just think `Make` does a pretty good job
> at things, and really shouldn't have to rely on anything it shouldn't
> _have_ to.
The following truly ugly shell script should do the job. It cuts out
comments, turns tabs into newlines, turns spaces into newlines, and then
edits out all the blank lines.
sed -e 's/\#.*//' | sed -e 's/\t/\n/' | sed -e 's/ /\n/' | sed -n -e '/./P'
Make should be able to use something along the lines of
TARGETS := $(shell sed -e 's/\#.*//' config | sed -e 's/\t/\n/' |
sed -e 's/ /\n/' | sed -n -e '/./P' )
Which just goes to show how far you can abuse a really tiny bit of knowledge.
It happily chomps on config files that look like:
# this is a comment
target_one target_two #more comments
> Changing the default for using snapshots may be a good idea. As you
> stated, anyone new to BuildRoot should probably try with stable releases
> first, and then experiment with "unstable" code. Also, as you stated,
> anybody that wants to use the unstable codebases by default should
> probably know enough to edit the Makefile anyway.
I'm pretty sure about this one. :)
> This brings me to my next point. Any user that is using the BuildRoot
> system should be comfortbale with the syntax of a Makefile, and should
> be confident in editing them as well. I know that this may seem a
> little harsh to newcomers, but this really is not the project for them.
There's a difference between being comfortable with makefile syntax and having
to wade halfway into the guts of a program to find the tunables that really
should be broken out into a #define in a header file. (I know C, that
doesn't mean I want to spend half an hour reading a program to find out where
it stores its buffer size or something like that.)
> The current buildsystem is simple, efficient, and developer-friendly.
> Franakly, anybody looking to build a system from the ground up will
> _need_ to know the basics of compiling packages and making any
> modifications necessary to make them work with the BuildRoot system.
I've now figured out that I got bit by the fact that gzip is not set up to
cross-compile. (It was a target I added from the make directory, and it
overwrote the gzip in my host system. All the example targets were set up to
Yeah, I survived. But I'd prefer if future survivors had some kind of warning
first about these little gotchas.
> Again, I am sorry if this seems cold-hearted toward lesser experienced
> users, but there are many wonderfull sources of information on the
> Internet regarding Makefiles, the `make` utility, and their inner
I understand make file syntax well enought to change it, and I think it's a
bad idea to have easily seperable configuration data buried in the makefile
like this. It has nothing to do with whether you understand makefile syntax.
> To answer your question regarding "USE_UCLIBC_TOOLCHAIN", this option
> tells the BuildRoot system to compile a "Compiler Toolchain". If you're
> crosscompiling, and want to compile a compiler to compile BuildRoot,
> you'll need this.
I'd gathered that. Perhaps I should document it more clearly. (I'm going to
HTML-ize the HOWTO and try to re-sort the information a bit so there's a
clearer walkthrough, "now what can you add to the base system", and possibly
better explanations on what various bits do. (Anatomy of a build
> If you're compiling on the same architecture, there's
> no harm in using it.
i386 on glibc and i386 on uclibc are effectively not the same architecture,
so their first time in just about everybody needs to cross-compile. And
unless you intend to set up your laptop to use uclibc (which I just might,
but it's a ways off), you're going to go on cross-compiling for some time.
> I do for some projects, and others I do not. One
> compelling reason to use the toolchain, regardless of cross-compiling or
> not, is a common problem with Configure scripts, broken Makefiles, and
> badly behaving link commands. This can be resolved by telling the
> package to compile itself with the newly compiled toolchain, or by
> bashing developers with a shovel, and breaking some bad habbits.
I'm all for the toolchain. I LIKE the toolchain. The question is why is the
toolchain target treated so much differently from any other target? If
you're going to use buildroot WITHOUT the toolchain, do you need to be
running it in a uclibc-based development environment?
The makefile uses the USE_UCLIBC_TOOLCHAIN guard as an #ifdef around a target
that's already in the target configuration section, which is just odd. (You
should edit all these targets by hand, except for THIS one go up to some
other section of the file and twiddle an #ifdef. Be consistent, guys...)
Very little else in the make directory uses this #define. uclibc_toolchain.mk
uses it to switch itself on, and uclibc.mk uses it to switch itself off. If
either of those is defining stuff that affects the rest of the build process,
it would be nice to document that. Otherwise, it's just a question of which
targets get enabled and they don't need the #ifdefs.
The only one to make any serious use of it is gcc_target, and I was kind of
hoping Eric would clue me in on what's going on there...
My main question is when you DON'T use the toolchain to cross-compile and
build a root_fs, what use is it expected to be put to, in what environment?
> Usually, these badly behaving packages are small in size, or complicated
> to convert to a new build system. I'm sure the developers of these
> packages would appreciate any help they could get with converting to a
> better system, and I know that I would too :-P
I'm all for it, but one problem at a time...
> Anyway, I hope this helps, and that it wasn't too long. Good luck, and
> Keep Us Posted (tm).
I'm up to my neck in about 8 projects, pretty much round-robining them, but
I'm making progress on this one... :)
> Thomas Cameron
> CEI Systems
-------------- next part --------------
# The toolchain comes first if we are building one
# Do you want user mode Linux (x86 only), or are you building a
# real kernel # that will run on its own? Perhaps you have a
# kernel you have already configured and you want to use that?
# The default minimal set
#zlib openssl openssh
# Everything needed to build a full uClibc development system!
#coreutils findutils bash ed flex bison file
#make diffutils patch sed gawk tar grep gcc_target
# Of course, if you are installing a development system, you
# may want some header files so you can compile stuff....
#ncurses-headers zlib-headers openssl-headers
# More development system stuff for those that want it
#m4 autoconf automake libtool
# Some nice debugging tools
# The Valgrind debugger (x86 only)
# Some stuff for access points and firewalls
#iptables hostap wtools dhcp_relay bridge
# Run customize.mk at the very end to add your own special config.
# This is useful for making your own distro within the buildroot
# Pick your root filesystem type.
# Must mount cramfs with 'ramdisk_blocksize=4096'
# You may need to edit make/jffs2root.mk to change target
# endian-ness or similar, but this is sufficient for most
# things as-is...
More information about the uClibc