Toybox is tested against two compilers (llvm, gcc) and three C libraries -(bionic, musl, glibc) in the following combinations:
+Toybox supports the standard $CROSS_COMPILE prefix environnment variable, +same as the Linux kernel build uses. This is used to prefix all the tools +(target-cc, target-ld, target-strip) during the build, meaning the prefix +usually ends with a "-" that's easy to forget but kind of important +("target-cc" and "targetcc" are not the same name).
+ +You can either provide a +full path in the CROSS_COMPILE string, or add the appropriate bin directory +to your $PATH. I.E:
+ +++ +make LDFLAGS=--static CROSS_COMPILE=~/musl-cross-make/ccc/m68k-linux-musl-cross/bin/m68k-linux-musl- distclean defconfig toybox
+
Is equivalent to:
+ ++ ++export "PATH=~/musl-cross-make/ccc/m68k-linux-musl-cross/bin:$PATH"
+LDFLAGS=--static CROSS_COMPILE=m68k-linux-musl- make distclean defconfig toybox +
(Both of those examples use static linking so you can install just +the single file to target, or test them with "qemu-m68k toybox". Feel free +to dynamically link instead if you prefer, mkroot offers a "dynamic" +add-on to copy the compiler's shared libraries into the new root +filesystem.)
+ +Toybox's system builder can use a simpler $CROSS +variable to specify the target(s) to build for if you've installed +compatible cross compilers under the "ccc" directory. +Behind the scenes this uses wildcard expansion to set $CROSS_COMPILER to +an appropriate path/prefix-.
+ +Toybox runs on 64 bit and 32 bit processors, little endian and big endian, +tries to respect alignment, and will enable nommu support when fork() is +unavailable (or when TOYBOX_FORCE_NOMMU is enabled in the config to +work around broken nommu toolchains), but otherwise tries to be +processor agnostic (although some commands such as strace can't avoid +a processor-specific if/else staircase.).
+ +Several commands (such as ps/top) are unavoidably full of Linux assumptions. +Some subset of the commands have been made to run on BSD and MacOS X, and +lib/portability.* and scripts/genconfig.sh exist to catch some known +variations.
+ + +Each release gets tested against two compilers (llvm, gcc), three C +libraries (bionic, musl, glibc), and a half-dozen different processor +types, in the following combinations:
@@ -554,15 +603,15 @@ installed on the system alongside the static binary: These days glibc is maintained by a committee instead of a single maintainer, if that's an improvement. (As with Windows and -Cobol, most people deal with it and get on with their lives.) +Cobol, most people just try to get on with their lives.) -The cross compilers I test this with are built from the +
These cross compilers are built from the musl-libc maintainer's musl-cross-make -project, built by running toybox's scripts/mcm-buildall.sh in that directory, +project, built by running toybox's scripts/mcm-buildall.sh in that directory, and then symlink the resulting "ccc" subdirectory into toybox where "make root CROSS=" can find them, ala:
@@ -575,7 +624,14 @@ cd musl-cross-make ln -s $(realpath ccc) ../toybox/ccc -Instead of symlinking ccc, you can specify a CROSS_COMPILE= prefix +
Since this takes a long time to run, and builds lots of targets +(cross and native), we've uploaded +the resulting binaries +so you can wget and extract a tarball or two instead of +compiling them all yourself. (See the README in that directory for details. +Yes there's a big source tarball in there for license compliance reasons.)
+ +Instead of CROSS= you can also specify a CROSS_COMPILE= prefix in the same format the Linux kernel build uses. You can either provide a full path in the CROSS_COMPILE string, or add the appropriate bin directory to your $PATH. I.E:
@@ -591,14 +647,14 @@ export "PATH=~/musl-cross-make/ccc/m68k-linux-musl-cross/bin:$PATH"Note: these examples use static linking becausae a dynamic musl binary +
Note: these examples use static linking because a dynamic musl binary won't run on your host unless you install musl's libc.so into the system libraries (which is an accident waiting to happen adding a second C library to most glibc linux distribution) or play with $LD_LIBRARY_PATH. -In theory you could "make root" a dynamic root filesystem with musl by copying -the shared libraries out of the toolchain, but I haven't bothered implementing -that in mkroot yet because a static linked musl hello world is 10k on x86 -(5k if stripped).
+(The dynamic package +in mkroot copies the shared libraries out of the toolchain to create a dynamic +linking environment in the root filesystem, but it's not nearly as well +tested.)