- 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
