toybox

The special name "." indicates the current directory (just like ".." means the parent directory), and you can run a program that isn't in the $PATH by specifying a path to it, so this should work: The file "configure" defines default values for many environment variables that control the toybox build; if you set a value for any of these, your value is used instead of the default in that file. The CROSS COMPILE argument above is optional, the default builds a version of toybox to run on the current machine. Cross compiling requires an appropriately prefixed cross compiler toolchain, several example toolchains are available at: For the "CROSS COMPILE=armv5l-" example above, download cross-compiler-armv5l.tar.bz2, extract it, and add its "bin" subdirectory to your $PATH. (And yes, the trailing - is significant, because the prefix includes a dash.) The toybox build produces a multicall binary, a "swiss-army-knife" program that acts differently depending on the name it was called by (cp, mv, cat...). Installing toybox adds symlinks for each command name to the $PATH. The special "toybox" command treats its first argument as the command to run. With no arguments, it lists available commands. This allows you to use toybox without installing it. This is the only command that can have an arbitrary suffix (hence "toybox-armv5l"). The maximum sane configuration is "make defconfig": allyesconfig isn't recommended for toybox because it enables unfinished commands and debug code. Toybox is not a complete operating system, it's a program that runs under an operating system. Booting a simple system to a shell prompt requires three packages: an operating system kernel (Linux ) to drive the hardware, one or more programs for the system to run (toybox), and a C library ("libc") to tie them together (toybox has been tested with musl, uClibc, glibc, and bionic). Static linking (with the --static option) copies the shared library contents into the program, resulting in larger but more portable programs, which can run even if they're the only file in the filesystem. Otherwise, the "dynamically" linked programs require the library files to be present on the target system ("man ldd" and "man ld.so" for details). That's designed to run under qemu, emulating several different hardware architectures (x86, x86-64, arm, mips, sparc, powerpc, sh4). Each toybox release is regression tested by building Linux From Scratch under this toybox-based system on each supported architecture, using QEMU to emulate big and little endian systems with different word size and alignment requirements. (The eventual goal is to replace Linux From Scratch with the Android Open Source Project.) Or something providing the same API such as FreeBSD's Linux emulation layer. 2) "Why Public Domain?" The rise and fall of copyleft, Ohio LinuxFest 2013 Although I do accept pull requests on github, I download the patches and apply them with "git am" (which avoids gratuitous merge commits). Closing the pull request is then the submitter's responsibility. Android's policy for toybox patches is that non-build patches should go upstream first (into vanilla toybox, with discussion on the toybox mailing list) and then be pulled into android's toybox repo from there. (They generally resync on fridays). The exception is patches to their build scripts (Android.mk and the checked-in generated/ files) which go directly to AOSP.