the lib (due to bug in gcc; see comment.)
I would have run the testsuite to check if everything is still behaving, but
unfortunately i cannot run the testsuite anymore: it just sits there and does
nothing even with a pristine checkout and an old gcc.
srcdir=/tmp/busybox/testsuite /tmp/busybox/testsuite/runtest
PASS: Applet order
FAIL: Common typos
PASS: Obsolete function usage
PASS: Obsolete function usage
<spins, ^C>
make[1]: *** [check] Interrupt
make: *** [check] Interrupt
I've just corrected that wrong double-printing.
Anyway. with gcc-4.1-HEAD from earlier today, we now have for
defconfig+ COMPILE_AT_ONCE:
880 -rwxr-xr-x 1 433 433 893476 Apr 28 21:41 busybox.oorig-4.0
860 -rwxr-xr-x 1 433 433 874560 Apr 28 21:36 busybox.oorig
844 -rwxr-xr-x 1 433 433 858752 Apr 28 21:49 busybox
text data bss dec hex filename
879920 11568 1039148 1930636 1d758c busybox.oorig-4.0
862802 10192 1038796 1911790 1d2bee busybox.oorig
848066 9100 1037536 1894702 1ce92e busybox
values for 4.0.2 just added for reference..
$(srcdir) can't bind early since it's set to a different value in each subdir.
If it binds early, it's blank, hence an empty -I which eats the next option
as a directory to look for #include files in.
So CFLAGS has to bind late, but the check_gcc stuff should only get run once.
I added a "make V=2" mode to show when check_gcc gets run, and turned WARNINGS
into a CFLAGS line since it was always getting added anyway.
e.g. archival/uncompress.c wrongly includes libbb.h instead of busybox.h
decompress_bunzip2.c,open_transformer.c don't include the proper "unarchive.h"
etc, etc.
- don't overwrite objects in the archive. Affected applets with name-clash
mostly vs. libbb:
iplink_main
iproute_main
iptunnel_main
login_main
run_parts_main
Very unreliable as e.g the ld check will see the flags supported by each emulation, not just the active one.
good enough for now..
Fix would be to crate one or more dummy .c files and accually try if a flag
works.
- add some filesystem operation wrapper variables for use in the makefiles and
pull them in early in the toplevel makefile
- use the cross-toolchain for "make sizes"
to test, checkout the source (let's assume /scratch/src/busybox), then
mkdir /tmp/bb ; cd /tmp/bb
make top_srcdir=/scratch/src/busybox O="$(pwd)" -f /scratch/src/busybox/Makefile allyesconfig check
- default to O=$(pwd) if no O was specified. Now you can just specify
the top_srcdir (without O=/somewhere) to create the obj-tree in pwd.
- make "make configtarget buildtarget" work. Previously this didn't
work due to how HAVE_DOT_CONFIG was evaluated. Two separate steps were
needed before, e.g. make config ; make busybox.
- remove some unneeded variables from Rules.mak (BB_SRC_DIR from Mr.
ldoolitt@recycle.lbl) which suggest that the stuff fixed above
didn't work before.
- move selinux libraries to where they belong (from Makefile to Rules.mak)
- update the docs to mention svn instead of cvs and provide an example
for building out-of-tree in INSTALL.
I've noticed that when I compile busybox on my laptop, it compiles more
slowly than one would expect, and although it's a (more-or-less)
multiprocessor system and I use -j5, make never seems to run more than
one job at a time.
I believe I have found the culprit: each time a file is compiled, gcc
runs about 5 times. This is because the $(check_gcc) macros and the
TARGET_ARCH macros are late binding.
The attached patch cuts the compilation time by 66%, from 1.5 minutes to
30 seconds. Your mileage may very. These statements have not been
evaluated by the FDA.
Hi!
I've created a patch to busybox' build system to allow building it in
separate tree in a manner similar to kbuild from kernel version 2.6.
That is, one runs command like
'make O=/build/some/where/for/specific/target/and/options'
and everything is built in this exact directory, provided that it exists.
I understand that applyingc such invasive changes during 'release
candidates' stage of development is at best unwise. So, i'm currently
asking for comments about this patch, starting from whether such thing
is needed at all to whether it coded properly.
'make check' should work now, and one make creates Makefile in build
directory, so one can run 'make' in build directory after that.
One possible caveat is that if we build in some directory other than
source one, the source directory should be 'distclean'ed first.
egor
