X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;f=Config.in;h=fa48ddd63346cb257b6675755c5de96689094db2;hb=599bbfbd9be0073c262319a120174fad5a60113e;hp=64281f03e2c85a532d5dc255922ad32e3683147f;hpb=def88985966a9351911844d42e06b735977bcb72;p=oweals%2Fbusybox.git diff --git a/Config.in b/Config.in index 64281f03e..fa48ddd63 100644 --- a/Config.in +++ b/Config.in @@ -186,10 +186,10 @@ config FEATURE_SUID_CONFIG The file has to be owned by user root, group root and has to be writeable only by root: - (chown 0.0 /etc/busybox.conf; chmod 600 /etc/busybox.conf) + (chown 0.0 /etc/busybox.conf; chmod 600 /etc/busybox.conf) The busybox executable has to be owned by user root, group root and has to be setuid root for this to work: - (chown 0.0 /bin/busybox; chmod 4755 /bin/busybox) + (chown 0.0 /bin/busybox; chmod 4755 /bin/busybox) Robert 'sandman' Griebl has more information here: . @@ -283,14 +283,15 @@ config STATIC config BUILD_LIBBUSYBOX bool "Build shared libbusybox" default n + depends on !FEATURE_PREFER_APPLETS help - Build a shared library libbusybox.so which contains all - libraries used inside busybox. + Build a shared library libbusybox.so.N.N.N which contains all + busybox code. - This is an experimental feature intended to support the upcoming - "make standalone" mode. Enabling it against the one big busybox - binary serves no purpose (and increases the size). You should - almost certainly say "no" to this right now. + This feature allows every applet to be built as a tiny + separate executable. Enabling it for "one big busybox binary" + approach serves no purpose and increases code size. + You should almost certainly say "no" to this. ### config FEATURE_FULL_LIBBUSYBOX ### bool "Feature-complete libbusybox" @@ -311,24 +312,32 @@ config BUILD_LIBBUSYBOX ### ### Say 'N' if in doubt. +config FEATURE_INDIVIDUAL + bool "Produce a binary for each applet, linked against libbusybox" + default y + depends on !STATIC && BUILD_LIBBUSYBOX + help + If your CPU architecture doesn't allow for sharing text/rodata + sections of running binaries, but allows for runtime dynamic + libraries, this option will allow you to reduce memory footprint + when you have many different applets running at once. + + If your CPU architecture allows for sharing text/rodata, + having single binary is more optimal. + + Each applet will be a tiny program, dynamically linked + against libbusybox.so.N.N.N. + + You need to have a working dynamic linker. + config FEATURE_SHARED_BUSYBOX bool "Produce additional busybox binary linked against libbusybox" - default y if BUILD_LIBBUSYBOX + default y depends on !STATIC && BUILD_LIBBUSYBOX help - You need to have a working dynamic linker to use this variant. + Build busybox, dynamically linked against libbusybox.so.N.N.N. -config LFS - bool "Build with Large File Support (for accessing files > 2 GB)" - default n - select FDISK_SUPPORT_LARGE_DISKS - help - If you want to build BusyBox with large file support, then enable - this option. This will have no effect if your kernel or your C - library lacks large file support for large files. Some of the - programs that can benefit from large file support include dd, gzip, - cp, mount, tar, and many others. If you want to access files larger - than 2 Gigabytes, enable this option. Otherwise, leave it set to 'N'. + You need to have a working dynamic linker. ### config BUILD_AT_ONCE ### bool "Compile all sources at once" @@ -349,6 +358,18 @@ config LFS ### ### Say 'N' unless you know what you are doing. +config LFS + bool "Build with Large File Support (for accessing files > 2 GB)" + default n + select FDISK_SUPPORT_LARGE_DISKS + help + If you want to build BusyBox with large file support, then enable + this option. This will have no effect if your kernel or your C + library lacks large file support for large files. Some of the + programs that can benefit from large file support include dd, gzip, + cp, mount, tar, and many others. If you want to access files larger + than 2 Gigabytes, enable this option. Otherwise, leave it set to 'N'. + endmenu menu 'Debugging Options'