toybox made more portable(improves NetBSD support)
  • C 72.2%
  • HTML 17.3%
  • Shell 10.3%
  • Python 0.1%
  • Makefile 0.1%
Find a file
kento2 4bd2ab5709
Some checks failed
toybox CI / MacOS-13 (push) Has been cancelled
toybox CI / Ubuntu-22_04 (push) Has been cancelled
improve portability/netbsd support
2026-10-11 13:58:34 +02:00
.github/workflows Work around another gcc bug, where --as-needed breaks libasan. This 2025-07-02 13:04:51 -05:00
kconfig improve portability/netbsd support 2026-10-11 13:58:34 +02:00
lib improve portability/netbsd support 2026-10-11 13:58:34 +02:00
mkroot Don't get confused by blah-cross.tar.gz in the ccc directory. 2026-06-23 01:45:18 -05:00
scripts improve portability/netbsd support 2026-10-11 13:58:34 +02:00
tests Apparently having an output file named the same as an input file is 2026-10-09 11:44:08 -05:00
toys Apparently having an output file named the same as an input file is 2026-10-09 11:44:08 -05:00
www Release 0.8.15 2026-10-02 16:31:14 -05:00
.gitignore Fix .gitignore complaining about name collisions in subdirectories. 2024-04-02 01:54:56 -05:00
Config.in More build cleanup. 2026-02-22 17:11:16 -06:00
configure Move -Wno-string-plus-int to portability.sh and have it only apply to clang. 2022-09-14 02:43:39 -05:00
LICENSE The title line is confusing github's license detector thingy. 2019-02-14 13:48:02 -06:00
main.c improve portability/netbsd support 2026-10-11 13:58:34 +02:00
Makefile Make kconfig/Makefile include optional. 2026-02-22 17:36:49 -06:00
README Update the README a bit. 2026-10-07 00:57:14 -05:00
toys.h Release 0.8.15 2026-10-02 16:31:14 -05:00
UNSUPPORTED improve portability/netbsd support 2026-10-11 13:58:34 +02:00

Toybox: all-in-one Linux command line.

Toybox combines many common Linux command line utilities together into a
single BSD-licensed executable. It's simple, small, fast, and reasonably
standards-compliant.

This project's website is at https://landley.net/toybox and static binaries
are available under https://landley.net/bin. The most up to date source code
is at https://landley.net/toybox/git and https://codeberg.org/landley/toybox.

--- Getting started

You can download static binaries for various targets from:

  http://landley.net/toybox/bin

So for example:

  wget http://landley.net/toybox/bin/toybox-x86_64 -O toybox
  chmod +x toybox
  ./toybox echo hello world
  ./toybox --help

(The ./ prefix is because it isn't in the $PATH.)

--- Building toybox

Type "make help" for build instructions.

Toybox uses the "make menuconfig; make; make install" idiom same as
the Linux kernel. Usually you want something like:

  make defconfig
  make
  make install

Or maybe:

  LDFLAGS="--static" CROSS_COMPILE=armv5l- make defconfig toybox
  PREFIX=/path/to/root/filesystem/bin make install_flat

The file "configure" defines default values for many environment variables
that control the toybox build; if you export any of these variables into your
environment, 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 (built using
the file "scripts/mcm-buildall.sh" in the toybox source) are available at:

  https://landley.net/bin/toolchains/latest

To cross compile with the provided toolchains similar to the above example,
download armv5l-linux-musleabihf-cross.tar.xz, extract it, add its "bin"
subdirectory to your $PATH, and use CROSS_COMPILE=armv5l-linux-musleabihf-
(yes the trailing - is significant, the prefix includes a dash.)

For more about cross compiling, see:

  https://landley.net/toybox/faq.html#cross
  http://landley.net/writing/docs/cross-compiling.html
  http://landley.net/aboriginal/architectures.html

For a more thorough description of the toybox build process, see:

  http://landley.net/toybox/code.html#building

--- Using toybox

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, and is the only command that can have/ignore an arbitrary
suffix (such as "toybox-armv5l").

The "help" command provides information about each command (ala "help cat"),
and "help toybox" provides general information about toybox. The --help option
to each command provides the same output. For commands that don't acknowledge
a --help option (true, false, test...) you can instead use "toybox --help true"
rather than "toybox true --help".

--- Configuring toybox

It works like the Linux kernel: allnoconfig, defconfig, and menuconfig edit
a ".config" file that selects which features to include in the resulting
binary. You can save and re-use your .config file, but may want to
run "make oldconfig" to re-run the dependency resolver when migrating to
new versions.

The maximum sane configuration is "make defconfig": allyesconfig isn't
recommended as a starting point for toybox because it enables unfinished
commands, debug code, and optional dependencies your build environment may
not provide.

--- Creating a Toybox-based Linux system

Toybox has a built-in simple system builder called "mkroot":

  mkroot/mkroot.sh
  such chroot root/host/fs /init

Type "exit" to get back out.

If you install appropriate cross compilers and point it at Linux source code,
it can build simple three-package systems that boot to a shell prompt under
qemu:

  mkroot/mkroot.sh CROSS_COMPILE=s390x-linux-musl- LINUX=~/linux
  root/s390x/run-qemu.sh

The directory mkroot/packages contains additional packages you can list
on the mkroot command line. Any argument with an = in it sets an environment
variable to control mkroot's behavior (see mkroot/README), everything else
is treated as a package name that runs a script out of that directory.
See mkroot/packages/dropbear for an example.

The FAQ explains this in a lot more detail:

  https://landley.net/toybox/faq.html#system
  https://landley.net/toybox/faq.html#mkroot

--- Presentations

1) "Why is Toybox?" talk at the Embedded Linux Conference in 2013

    outline: http://landley.net/talks/celf-2013.txt
    video: http://youtu.be/SGmtP5Lg_t0

    The https://landley.net/toybox/about.html page has nav links breaking that
    talk down into sections.

2) "Why Public Domain?" The rise and fall of copyleft, Ohio LinuxFest 2013

    outline: http://landley.net/talks/ohio-2013.txt
    audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3

3) Why did I do Aboriginal Linux (which led me here)

    260 slide presentation:
      https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu

    How and why to make android self-hosting:
      http://landley.net/aboriginal/about.html#selfhost

    More backstory than strictly necessary:
      https://landley.net/aboriginal/history.html

4) What's new with toybox (ELC 2015 status update)

    video: http://elinux.org/ELC_2015_Presentations
    outline: http://landley.net/talks/celf-2015.txt

5) Building the simplest possible Linux System (ELC 2017, so very jetlagged)

    video: https://www.youtube.com/watch?v=Sk9TatW9ino

6) Toybox vs BusyBox (2019 ELC talk)

    outline: http://landley.net/talks/elc-2019.txt
    video: https://www.youtube.com/watch?v=MkJkyMuBm3g

7) Intro to mkroot (2026 ELC talk)

    video: https://www.youtube.com/watch?v=vM_Gbx-c2Qs

--- Contributing

The three important URLs for communicating with the toybox project are:

  web page: http://landley.net/toybox

  mailing list: https://lists.landley.net/mailman/listinfo/toybox

  git repo: https://codeberg.org/landley/toybox

The maintainer prefers patches be sent to the mailing list. If you use git,
the easy thing to do is:

  git format-patch -1 $HASH

Then send a file attachment. The list holds messages from non-subscribers
for moderation, but I usually get to them in a day or two.

I download codeberg pull requests as patches and apply them with "git am"
(which avoids gratuitous merge commits). Sometimes I even remember to close
the pull request.

If I haven't responded to your patch after one week, feel free to remind
me of it.

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.

(As for the other meaning of "contributing", https://patreon.com/landley is
always welcome but I warn you up front I'm terrible about updating it.)