2004-10-09 03:06:03 +02:00
|
|
|
#
|
|
|
|
|
|
2011-02-02 14:53:23 +01:00
|
|
|
mainmenu "Buildroot $BR2_VERSION Configuration"
|
2004-10-09 03:06:03 +02:00
|
|
|
|
|
|
|
|
config BR2_HAVE_DOT_CONFIG
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
2007-09-25 13:37:31 +02:00
|
|
|
config BR2_VERSION
|
|
|
|
|
string
|
2010-10-31 17:35:14 +01:00
|
|
|
option env="BR2_VERSION_FULL"
|
2007-09-25 13:37:31 +02:00
|
|
|
|
2012-07-18 15:59:09 +02:00
|
|
|
config BR2_HOSTARCH
|
|
|
|
|
string
|
|
|
|
|
option env="HOSTARCH"
|
|
|
|
|
|
2019-07-29 22:19:53 +02:00
|
|
|
config BR2_BASE_DIR
|
2016-07-17 12:34:26 +02:00
|
|
|
string
|
2019-07-29 22:19:53 +02:00
|
|
|
option env="BASE_DIR"
|
2016-07-17 12:34:26 +02:00
|
|
|
|
2019-07-29 22:19:59 +02:00
|
|
|
# br2-external paths definitions
|
|
|
|
|
source "$BR2_BASE_DIR/.br2-external.in.paths"
|
|
|
|
|
|
2015-12-31 01:34:13 +01:00
|
|
|
# Hidden config symbols for packages to check system gcc version
|
|
|
|
|
config BR2_HOST_GCC_VERSION
|
|
|
|
|
string
|
|
|
|
|
option env="HOST_GCC_VERSION"
|
|
|
|
|
|
|
|
|
|
config BR2_HOST_GCC_AT_LEAST_4_9
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "4 9"
|
|
|
|
|
|
|
|
|
|
config BR2_HOST_GCC_AT_LEAST_5
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "5"
|
|
|
|
|
select BR2_HOST_GCC_AT_LEAST_4_9
|
|
|
|
|
|
2016-06-06 12:18:14 +02:00
|
|
|
config BR2_HOST_GCC_AT_LEAST_6
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "6"
|
|
|
|
|
select BR2_HOST_GCC_AT_LEAST_5
|
|
|
|
|
|
2017-07-05 15:06:33 +02:00
|
|
|
config BR2_HOST_GCC_AT_LEAST_7
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "7"
|
|
|
|
|
select BR2_HOST_GCC_AT_LEAST_6
|
|
|
|
|
|
2018-05-02 12:09:04 +02:00
|
|
|
config BR2_HOST_GCC_AT_LEAST_8
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "8"
|
|
|
|
|
select BR2_HOST_GCC_AT_LEAST_7
|
|
|
|
|
|
2020-02-25 22:22:13 +01:00
|
|
|
config BR2_HOST_GCC_AT_LEAST_9
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "9"
|
|
|
|
|
select BR2_HOST_GCC_AT_LEAST_8
|
|
|
|
|
|
2023-11-03 01:06:49 +01:00
|
|
|
config BR2_HOST_GCC_AT_LEAST_10
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "10"
|
|
|
|
|
select BR2_HOST_GCC_AT_LEAST_9
|
|
|
|
|
|
|
|
|
|
config BR2_HOST_GCC_AT_LEAST_11
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_HOST_GCC_VERSION = "11"
|
|
|
|
|
select BR2_HOST_GCC_AT_LEAST_10
|
|
|
|
|
|
2018-10-23 11:08:40 +02:00
|
|
|
# When adding new entries above, be sure to update
|
|
|
|
|
# the HOSTCC_MAX_VERSION variable in the Makefile.
|
|
|
|
|
|
2014-02-18 00:37:12 +01:00
|
|
|
# Hidden boolean selected by packages in need of Java in order to build
|
2017-10-01 21:04:30 +02:00
|
|
|
# (example: kodi)
|
2014-02-19 16:33:50 +01:00
|
|
|
config BR2_NEEDS_HOST_JAVA
|
2014-02-18 00:37:12 +01:00
|
|
|
bool
|
|
|
|
|
|
2012-12-29 07:14:49 +01:00
|
|
|
# Hidden boolean selected by pre-built packages for x86, when they
|
|
|
|
|
# need to run on x86-64 machines (example: pre-built external
|
2023-03-15 17:21:11 +01:00
|
|
|
# toolchains, binary tools, etc.).
|
2012-12-29 07:14:49 +01:00
|
|
|
config BR2_HOSTARCH_NEEDS_IA32_LIBS
|
|
|
|
|
bool
|
|
|
|
|
|
2013-11-11 17:47:25 +01:00
|
|
|
# Hidden boolean selected by packages that need to build 32 bits
|
|
|
|
|
# binaries with the host compiler, even on 64 bits build machines (e.g
|
|
|
|
|
# bootloaders).
|
|
|
|
|
config BR2_HOSTARCH_NEEDS_IA32_COMPILER
|
|
|
|
|
bool
|
|
|
|
|
|
2016-12-04 10:43:04 +01:00
|
|
|
# Hidden boolean selected by packages that need the host to have an
|
|
|
|
|
# UTF8 locale.
|
|
|
|
|
config BR2_NEEDS_HOST_UTF8_LOCALE
|
|
|
|
|
bool
|
|
|
|
|
|
2020-07-06 17:30:35 +02:00
|
|
|
# Hidden boolean selected by packages that need the host to have
|
|
|
|
|
# support for building gcc plugins
|
|
|
|
|
config BR2_NEEDS_HOST_GCC_PLUGIN_SUPPORT
|
|
|
|
|
bool
|
|
|
|
|
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 09:27:59 +01:00
|
|
|
source "arch/Config.in"
|
2007-07-08 18:28:54 +02:00
|
|
|
|
2021-10-06 22:41:33 +02:00
|
|
|
source "toolchain/Config.in"
|
|
|
|
|
|
2004-12-11 14:01:10 +01:00
|
|
|
menu "Build options"
|
|
|
|
|
|
2010-04-10 22:55:01 +02:00
|
|
|
menu "Commands"
|
|
|
|
|
|
2004-10-09 03:06:03 +02:00
|
|
|
config BR2_WGET
|
2004-12-11 14:01:10 +01:00
|
|
|
string "Wget command"
|
2010-11-04 19:16:43 +01:00
|
|
|
default "wget --passive-ftp -nd -t 3"
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2010-09-02 12:09:45 +02:00
|
|
|
config BR2_SVN
|
|
|
|
|
string "Subversion (svn) command"
|
2017-11-17 19:50:34 +01:00
|
|
|
default "svn --non-interactive"
|
2005-01-23 12:20:30 +01:00
|
|
|
|
2010-09-02 12:09:45 +02:00
|
|
|
config BR2_BZR
|
|
|
|
|
string "Bazaar (bzr) command"
|
|
|
|
|
default "bzr"
|
2009-08-07 11:57:54 +02:00
|
|
|
|
2007-08-24 07:31:07 +02:00
|
|
|
config BR2_GIT
|
2010-09-02 12:09:45 +02:00
|
|
|
string "Git command"
|
|
|
|
|
default "git"
|
2007-08-24 07:31:07 +02:00
|
|
|
|
2013-09-11 14:12:04 +02:00
|
|
|
config BR2_CVS
|
|
|
|
|
string "CVS command"
|
|
|
|
|
default "cvs"
|
|
|
|
|
|
2011-09-29 21:57:46 +02:00
|
|
|
config BR2_LOCALFILES
|
|
|
|
|
string "Local files retrieval command"
|
|
|
|
|
default "cp"
|
|
|
|
|
|
2011-10-19 09:25:40 +02:00
|
|
|
config BR2_SCP
|
|
|
|
|
string "Secure copy (scp) command"
|
|
|
|
|
default "scp"
|
|
|
|
|
|
2020-04-15 18:48:45 +02:00
|
|
|
config BR2_SFTP
|
|
|
|
|
string "Secure file transfer (sftp) command"
|
|
|
|
|
default "sftp"
|
|
|
|
|
|
2011-10-19 09:25:47 +02:00
|
|
|
config BR2_HG
|
|
|
|
|
string "Mercurial (hg) command"
|
|
|
|
|
default "hg"
|
|
|
|
|
|
2006-10-01 17:07:45 +02:00
|
|
|
config BR2_ZCAT
|
|
|
|
|
string "zcat command"
|
2007-03-09 09:26:10 +01:00
|
|
|
default "gzip -d -c"
|
2006-10-01 17:07:45 +02:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Command to be used to extract a gzip'ed file to stdout. zcat
|
|
|
|
|
is identical to gunzip -c except that the former may not be
|
|
|
|
|
available on your system.
|
2007-03-09 09:26:10 +01:00
|
|
|
Default is "gzip -d -c"
|
|
|
|
|
Other possible values include "gunzip -c" or "zcat".
|
2006-11-17 16:43:51 +01:00
|
|
|
|
|
|
|
|
config BR2_BZCAT
|
|
|
|
|
string "bzcat command"
|
|
|
|
|
default "bzcat"
|
|
|
|
|
help
|
|
|
|
|
Command to be used to extract a bzip2'ed file to stdout.
|
|
|
|
|
bzcat is identical to bunzip2 -c except that the former may
|
|
|
|
|
not be available on your system.
|
|
|
|
|
Default is "bzcat"
|
|
|
|
|
Other possible values include "bunzip2 -c" or "bzip2 -d -c".
|
2006-10-01 17:07:45 +02:00
|
|
|
|
2011-05-10 08:17:05 +02:00
|
|
|
config BR2_XZCAT
|
|
|
|
|
string "xzcat command"
|
|
|
|
|
default "xzcat"
|
|
|
|
|
help
|
|
|
|
|
Command to be used to extract a xz'ed file to stdout.
|
|
|
|
|
Default is "xzcat"
|
|
|
|
|
|
2017-02-12 21:15:39 +01:00
|
|
|
config BR2_LZCAT
|
|
|
|
|
string "lzcat command"
|
|
|
|
|
default "lzip -d -c"
|
|
|
|
|
help
|
|
|
|
|
Command to be used to extract a lzip'ed file to stdout.
|
|
|
|
|
Default is "lzip -d -c"
|
|
|
|
|
|
2005-12-10 15:59:02 +01:00
|
|
|
config BR2_TAR_OPTIONS
|
|
|
|
|
string "Tar options"
|
2005-12-10 16:36:43 +01:00
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
Options to pass to tar when extracting the sources.
|
2018-04-01 07:08:39 +02:00
|
|
|
E.g. " -v --exclude='*.svn*'" to exclude all .svn internal
|
|
|
|
|
files and to be verbose.
|
2005-12-10 15:59:02 +01:00
|
|
|
|
2010-04-10 22:55:01 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2013-02-06 22:50:57 +01:00
|
|
|
config BR2_DEFCONFIG_FROM_ENV
|
|
|
|
|
string
|
|
|
|
|
option env="BR2_DEFCONFIG"
|
|
|
|
|
|
|
|
|
|
config BR2_DEFCONFIG
|
|
|
|
|
string "Location to save buildroot config"
|
|
|
|
|
default BR2_DEFCONFIG_FROM_ENV if BR2_DEFCONFIG_FROM_ENV != ""
|
|
|
|
|
default "$(CONFIG_DIR)/defconfig"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
When running 'make savedefconfig', the defconfig file will be
|
|
|
|
|
saved in this location.
|
2013-02-06 22:50:57 +01:00
|
|
|
|
2005-10-01 02:35:24 +02:00
|
|
|
config BR2_DL_DIR
|
|
|
|
|
string "Download dir"
|
2009-09-23 08:46:52 +02:00
|
|
|
default "$(TOPDIR)/dl"
|
2005-10-01 02:35:24 +02:00
|
|
|
help
|
|
|
|
|
Directory to store all the source files that we need to fetch.
|
2014-02-04 16:18:51 +01:00
|
|
|
If the Linux shell environment has defined the BR2_DL_DIR
|
2016-05-31 18:57:22 +02:00
|
|
|
environment variable, then this overrides this configuration
|
|
|
|
|
item.
|
2018-04-17 14:54:45 +02:00
|
|
|
The directory is organized with a subdirectory for each
|
|
|
|
|
package. Each package has its own $(LIBFOO_DL_DIR) variable
|
|
|
|
|
that can be used to find the correct path.
|
2005-10-01 02:35:24 +02:00
|
|
|
|
2009-09-23 08:46:52 +02:00
|
|
|
The default is $(TOPDIR)/dl
|
2007-09-26 23:12:38 +02:00
|
|
|
|
2011-02-02 14:05:56 +01:00
|
|
|
config BR2_HOST_DIR
|
|
|
|
|
string "Host dir"
|
|
|
|
|
default "$(BASE_DIR)/host"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Directory to store all the binary files that are built for the
|
|
|
|
|
host. This includes the cross compilation toolchain when
|
|
|
|
|
building the internal buildroot toolchain.
|
2011-02-02 14:05:56 +01:00
|
|
|
|
|
|
|
|
The default is $(BASE_DIR)/host
|
|
|
|
|
|
2010-12-05 21:52:37 +01:00
|
|
|
menu "Mirrors and Download locations"
|
|
|
|
|
|
|
|
|
|
config BR2_PRIMARY_SITE
|
|
|
|
|
string "Primary download site"
|
|
|
|
|
default ""
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Primary site to download from. If this option is set then
|
|
|
|
|
buildroot will try to download package source first from this
|
|
|
|
|
site and try the default if the file is not found.
|
2015-11-18 10:03:25 +01:00
|
|
|
Valid URIs are:
|
|
|
|
|
- URIs recognized by $(WGET)
|
|
|
|
|
- local URIs of the form file://absolutepath
|
|
|
|
|
- scp URIs of the form scp://[user@]host:path.
|
2010-12-05 21:52:37 +01:00
|
|
|
|
2012-06-22 07:37:03 +02:00
|
|
|
config BR2_PRIMARY_SITE_ONLY
|
|
|
|
|
bool "Only allow downloads from primary download site"
|
|
|
|
|
depends on BR2_PRIMARY_SITE != ""
|
|
|
|
|
help
|
|
|
|
|
If this option is enabled, downloads will only be attempted
|
|
|
|
|
from the primary download site. Other locations, like the
|
|
|
|
|
package's official download location or the backup download
|
2016-05-31 18:57:22 +02:00
|
|
|
site, will not be considered. Therefore, if the package is not
|
|
|
|
|
present on the primary site, the download fails.
|
2012-06-22 07:37:03 +02:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
This is useful for project developers who want to ensure that
|
|
|
|
|
the project can be built even if the upstream tarball
|
2012-06-22 07:37:03 +02:00
|
|
|
locations disappear.
|
|
|
|
|
|
|
|
|
|
if !BR2_PRIMARY_SITE_ONLY
|
|
|
|
|
|
2010-12-05 21:52:37 +01:00
|
|
|
config BR2_BACKUP_SITE
|
|
|
|
|
string "Backup download site"
|
2023-10-27 14:12:51 +02:00
|
|
|
default "https://sources.buildroot.net"
|
2010-12-05 21:52:37 +01:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Backup site to download from. If this option is set then
|
|
|
|
|
buildroot will fall back to download package sources from here
|
|
|
|
|
if the normal location fails.
|
2010-12-05 21:52:37 +01:00
|
|
|
|
|
|
|
|
config BR2_KERNEL_MIRROR
|
|
|
|
|
string "Kernel.org mirror"
|
2016-05-23 17:36:53 +02:00
|
|
|
default "https://cdn.kernel.org/pub"
|
2010-12-05 21:52:37 +01:00
|
|
|
help
|
2016-05-23 17:36:53 +02:00
|
|
|
kernel.org is mirrored on a number of servers around the
|
2016-05-31 18:57:22 +02:00
|
|
|
world. The following allows you to select your preferred
|
2016-05-23 17:36:53 +02:00
|
|
|
mirror. By default, a CDN is used, which automatically
|
|
|
|
|
redirects to a mirror geographically close to you.
|
2010-12-05 21:52:37 +01:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
Have a look on the kernel.org site for a list of mirrors, then
|
|
|
|
|
enter the URL to the base directory. Examples:
|
2010-12-05 21:52:37 +01:00
|
|
|
|
|
|
|
|
http://www.XX.kernel.org/pub (XX = country code)
|
|
|
|
|
http://mirror.aarnet.edu.au/pub/ftp.kernel.org
|
|
|
|
|
|
|
|
|
|
config BR2_GNU_MIRROR
|
|
|
|
|
string "GNU Software mirror"
|
2016-05-24 20:48:26 +02:00
|
|
|
default "http://ftpmirror.gnu.org"
|
2010-12-05 21:52:37 +01:00
|
|
|
help
|
2016-05-24 20:48:26 +02:00
|
|
|
GNU has multiple software mirrors scattered around the
|
2016-05-31 18:57:22 +02:00
|
|
|
world. The following allows you to select your preferred
|
2016-05-24 20:48:26 +02:00
|
|
|
mirror. By default, a generic address is used, which
|
|
|
|
|
automatically selects an up-to-date and local mirror.
|
2010-12-05 21:52:37 +01:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
Have a look on the gnu.org site for a list of mirrors, then
|
|
|
|
|
enter the URL to the base directory. Examples:
|
2010-12-05 21:52:37 +01:00
|
|
|
|
|
|
|
|
http://ftp.gnu.org/pub/gnu
|
|
|
|
|
http://mirror.aarnet.edu.au/pub/gnu
|
|
|
|
|
|
2014-01-11 16:42:07 +01:00
|
|
|
config BR2_LUAROCKS_MIRROR
|
|
|
|
|
string "LuaRocks mirror"
|
2014-07-25 20:21:24 +02:00
|
|
|
default "http://rocks.moonscript.org"
|
2014-01-11 16:42:07 +01:00
|
|
|
help
|
|
|
|
|
LuaRocks repository.
|
|
|
|
|
|
|
|
|
|
See http://luarocks.org
|
|
|
|
|
|
2014-02-23 15:17:16 +01:00
|
|
|
config BR2_CPAN_MIRROR
|
|
|
|
|
string "CPAN mirror (Perl packages)"
|
2022-12-20 19:03:06 +01:00
|
|
|
default "https://cpan.metacpan.org"
|
2014-02-23 15:17:16 +01:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
CPAN (Comprehensive Perl Archive Network) is a repository of
|
|
|
|
|
Perl packages. It has multiple software mirrors scattered
|
2014-02-23 15:17:16 +01:00
|
|
|
around the world. This option allows you to select a mirror.
|
|
|
|
|
|
|
|
|
|
The list of mirrors is available at:
|
2022-12-20 19:03:06 +01:00
|
|
|
http://mirrors.cpan.org/ (tabular)
|
|
|
|
|
http://mirrors.cpan.org/map.html (clickable world map)
|
2014-02-23 15:17:16 +01:00
|
|
|
|
2015-07-14 09:42:40 +02:00
|
|
|
endif
|
|
|
|
|
|
2010-12-05 21:52:37 +01:00
|
|
|
endmenu
|
2010-04-10 22:55:38 +02:00
|
|
|
|
2004-12-11 14:01:10 +01:00
|
|
|
config BR2_JLEVEL
|
2012-06-16 11:37:17 +02:00
|
|
|
int "Number of jobs to run simultaneously (0 for auto)"
|
|
|
|
|
default "0"
|
2004-12-11 14:01:10 +01:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Number of jobs to run simultaneously. If 0, determine
|
|
|
|
|
automatically according to number of CPUs on the host system.
|
2007-01-28 13:03:58 +01:00
|
|
|
|
2010-12-07 21:09:56 +01:00
|
|
|
config BR2_CCACHE
|
|
|
|
|
bool "Enable compiler cache"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
This option will enable the use of ccache, a compiler cache.
|
|
|
|
|
It will cache the result of previous builds to speed up future
|
|
|
|
|
builds. By default, the cache is stored in
|
2010-12-07 21:09:56 +01:00
|
|
|
$HOME/.buildroot-ccache.
|
|
|
|
|
|
2012-03-07 20:26:50 +01:00
|
|
|
Note that Buildroot does not try to invalidate the cache
|
2016-05-31 18:57:22 +02:00
|
|
|
contents when the compiler changes in an incompatible way.
|
|
|
|
|
Therefore, if you make a change to the compiler version and/or
|
|
|
|
|
configuration, you are responsible for purging the ccache
|
|
|
|
|
cache by removing the $HOME/.buildroot-ccache directory.
|
2012-03-07 20:26:50 +01:00
|
|
|
|
2014-05-01 04:05:07 +02:00
|
|
|
if BR2_CCACHE
|
|
|
|
|
|
2012-05-16 21:39:28 +02:00
|
|
|
config BR2_CCACHE_DIR
|
|
|
|
|
string "Compiler cache location"
|
|
|
|
|
default "$(HOME)/.buildroot-ccache"
|
|
|
|
|
help
|
|
|
|
|
Where ccache should store cached files.
|
2018-03-15 22:47:33 +01:00
|
|
|
If the Linux shell environment has defined the BR2_CCACHE_DIR
|
|
|
|
|
environment variable, then this overrides this configuration
|
|
|
|
|
item.
|
2012-05-16 21:39:28 +02:00
|
|
|
|
2014-05-01 04:05:07 +02:00
|
|
|
config BR2_CCACHE_INITIAL_SETUP
|
|
|
|
|
string "Compiler cache initial setup"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Initial ccache settings to apply, such as --max-files or
|
|
|
|
|
--max-size.
|
2014-05-01 04:05:07 +02:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
For example, if your project is known to require more space
|
|
|
|
|
than the default max cache size, then you might want to
|
|
|
|
|
increase the cache size to a suitable amount using the -M
|
|
|
|
|
(--max-size) option.
|
2014-05-01 04:05:07 +02:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
The string you specify here is passed verbatim to ccache.
|
|
|
|
|
Refer to ccache documentation for more details.
|
2014-05-01 04:05:07 +02:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
These initial settings are applied after ccache has been
|
|
|
|
|
compiled.
|
2014-05-01 04:05:07 +02:00
|
|
|
|
2015-10-04 17:25:32 +02:00
|
|
|
config BR2_CCACHE_USE_BASEDIR
|
|
|
|
|
bool "Use relative paths"
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Allow ccache to convert absolute paths within the output
|
|
|
|
|
directory into relative paths.
|
|
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
During the build, many -I include directives are given with an
|
|
|
|
|
absolute path. These absolute paths end up in the hashes that
|
|
|
|
|
are computed by ccache. Therefore, when you build from a
|
|
|
|
|
different directory, the hash will be different and the cached
|
|
|
|
|
object will not be used.
|
2015-10-04 17:25:32 +02:00
|
|
|
|
|
|
|
|
To improve cache performance, set this option to y. This
|
|
|
|
|
allows ccache to rewrite absolute paths within the output
|
2016-05-31 18:57:22 +02:00
|
|
|
directory into relative paths. Note that only paths within the
|
|
|
|
|
output directory will be rewritten; therefore, if you change
|
|
|
|
|
BR2_HOST_DIR to point outside the output directory and
|
2015-10-04 17:25:32 +02:00
|
|
|
subsequently move it to a different location, this will lead
|
|
|
|
|
to cache misses.
|
|
|
|
|
|
|
|
|
|
This option has as a result that the debug information in the
|
|
|
|
|
object files also has only relative paths. Therefore, make
|
|
|
|
|
sure you cd to the build directory before starting gdb. See
|
2016-05-31 18:57:22 +02:00
|
|
|
the section "COMPILING IN DIFFERENT DIRECTORIES" in the ccache
|
|
|
|
|
manual for more information.
|
2015-10-04 17:25:32 +02:00
|
|
|
|
2014-05-01 04:05:07 +02:00
|
|
|
endif
|
|
|
|
|
|
2008-03-12 14:07:10 +01:00
|
|
|
config BR2_ENABLE_DEBUG
|
|
|
|
|
bool "build packages with debugging symbols"
|
|
|
|
|
help
|
2012-03-14 23:49:58 +01:00
|
|
|
Build packages with debugging symbols enabled. All libraries
|
|
|
|
|
and binaries in the 'staging' directory will have debugging
|
|
|
|
|
symbols, which allows remote debugging even if libraries and
|
|
|
|
|
binaries are stripped on the target. Whether libraries and
|
|
|
|
|
binaries are stripped on the target is controlled by the
|
|
|
|
|
BR2_STRIP_* options below.
|
2008-03-12 14:07:10 +01:00
|
|
|
|
|
|
|
|
if BR2_ENABLE_DEBUG
|
|
|
|
|
choice
|
|
|
|
|
prompt "gcc debug level"
|
|
|
|
|
default BR2_DEBUG_2
|
|
|
|
|
help
|
|
|
|
|
Set the debug level for gcc
|
|
|
|
|
|
|
|
|
|
config BR2_DEBUG_1
|
|
|
|
|
bool "debug level 1"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Debug level 1 produces minimal information, enough for making
|
|
|
|
|
backtraces in parts of the program that you don't plan to
|
|
|
|
|
debug. This includes descriptions of functions and external
|
|
|
|
|
variables, but no information about local variables and no
|
|
|
|
|
line numbers.
|
2008-03-12 14:07:10 +01:00
|
|
|
|
|
|
|
|
config BR2_DEBUG_2
|
|
|
|
|
bool "debug level 2"
|
|
|
|
|
help
|
|
|
|
|
The default gcc debug level is 2
|
|
|
|
|
|
|
|
|
|
config BR2_DEBUG_3
|
|
|
|
|
bool "debug level 3"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Level 3 includes extra information, such as all the macro
|
|
|
|
|
definitions present in the program. Some debuggers support
|
|
|
|
|
macro expansion when you use -g3.
|
2008-03-12 14:07:10 +01:00
|
|
|
endchoice
|
|
|
|
|
endif
|
|
|
|
|
|
core: introduce BR2_ENABLE_RUNTIME_DEBUG
Some packages have optional runtime assertions, extra traces, or other
elements that can help in debugging problems. However, such runtime elements
can negatively influence performance.
In a test program performing 100K gRPC calls from a client to a local server
and receiving the returned response, we see following execution time:
- runtime debug enabled: 1065 seconds
- runtime debug disabled: 48 seconds
This is more than a factor 20 (!) difference. Analysis shows that the
problem mostly stems from libabseil-cpp (a dependency of gRPC) which enables
mutex deadlock analysis when the preprocessor flag 'NDEBUG' is not set,
which adds a 'backtrace()' call on every lock/unlock. Potentially worse,
when libunwind is enabled and linked with the test program, 'backtrace()' is
not provided by glibc but by libunwind itself.
For production systems, users expect good performance out-of-the-box. In the
example above, the difference is huge and unless explicitly tested and
analyzed, users may not realize that the performance could be much better.
Address this problem by introducing a new option BR2_ENABLE_RUNTIME_DEBUG,
which can be used by packages or package infrastructures to set the
necessary flags.
Note that BR2_ENABLE_RUNTIME_DEBUG is orthogonal to BR2_ENABLE_DEBUG: the
former changes runtime behavior, while the latter is only expected to add
debug symbols to the build. Today, the cmake build system does introduce a
runtime impact when BR2_ENABLE_DEBUG is set, but that will be rectified in a
subsequent commit.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-06-01 16:34:06 +02:00
|
|
|
config BR2_ENABLE_RUNTIME_DEBUG
|
|
|
|
|
bool "build packages with runtime debugging info"
|
|
|
|
|
help
|
|
|
|
|
Some packages may have runtime assertions, extra traces, and
|
|
|
|
|
similar runtime elements that can help debugging. However,
|
|
|
|
|
these elements may negatively influence performance so should
|
|
|
|
|
normally not be enabled on production systems.
|
|
|
|
|
|
|
|
|
|
Enable this option to enable such runtime debugging.
|
|
|
|
|
|
|
|
|
|
Note: disabling this option is not a guarantee that all
|
|
|
|
|
packages effectively removed these runtime debugging elements.
|
|
|
|
|
|
2007-07-31 20:06:50 +02:00
|
|
|
config BR2_STRIP_strip
|
2017-07-01 14:51:21 +02:00
|
|
|
bool "strip target binaries"
|
|
|
|
|
default y
|
2022-07-20 04:45:25 +02:00
|
|
|
depends on BR2_BINFMT_ELF
|
2007-07-31 20:06:50 +02:00
|
|
|
help
|
2012-03-14 23:49:58 +01:00
|
|
|
Binaries and libraries in the target filesystem will be
|
2016-05-31 18:57:22 +02:00
|
|
|
stripped using the normal 'strip' command. This allows to save
|
|
|
|
|
space, mainly by removing debugging symbols. Debugging symbols
|
|
|
|
|
on the target are needed for native debugging, but not when
|
|
|
|
|
remote debugging is used.
|
2007-08-24 07:31:07 +02:00
|
|
|
|
2012-06-21 21:34:50 +02:00
|
|
|
config BR2_STRIP_EXCLUDE_FILES
|
|
|
|
|
string "executables that should not be stripped"
|
|
|
|
|
default ""
|
2018-04-01 07:08:33 +02:00
|
|
|
depends on BR2_STRIP_strip
|
2012-06-21 21:34:50 +02:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
You may specify a space-separated list of binaries and
|
|
|
|
|
libraries here that should not be stripped on the target.
|
2012-06-21 21:34:50 +02:00
|
|
|
|
|
|
|
|
config BR2_STRIP_EXCLUDE_DIRS
|
|
|
|
|
string "directories that should be skipped when stripping"
|
|
|
|
|
default ""
|
2018-04-01 07:08:33 +02:00
|
|
|
depends on BR2_STRIP_strip
|
2012-06-21 21:34:50 +02:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
You may specify a space-separated list of directories that
|
|
|
|
|
should be skipped when stripping. Binaries and libraries in
|
|
|
|
|
these directories will not be touched. The directories should
|
|
|
|
|
be specified relative to the target directory, without leading
|
|
|
|
|
slash.
|
2012-06-21 21:34:50 +02:00
|
|
|
|
2008-03-12 14:07:10 +01:00
|
|
|
choice
|
|
|
|
|
prompt "gcc optimization level"
|
Config.in: change default optimization level from -Os to -O2
Historically, Buildroot has defaulted to -Os as the gcc optimization
flags. However, this default is probably not the most appropriate
anymore, and this commit therefore changes the default to -O2.
Here are some arguments in favor of this change:
- Most Buildroot users use Buildroot for platforms that have a
reasonable amount of storage, and the difference between -Os and -O2
in terms of code size is no longer as significant compared to the
size of storage available on average embedded Linux devices
typically found these days.
- -Os can have a pretty bad performance impact, compared to -O2.
- -Os is much less widely tested than -O2. For example, with recent
versions of gcc, there are parts of Qt5 that segfault when compiled
with -Os and work perfectly fine with -O2. Yes, it's a compiler bug
that should be fixed, but in the mean time, having a default that's
more widely used/tested makes sense.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2024-01-02 09:36:42 +01:00
|
|
|
default BR2_OPTIMIZE_2
|
2008-03-12 12:23:11 +01:00
|
|
|
help
|
2008-03-12 14:07:10 +01:00
|
|
|
Set the optimization level for gcc
|
|
|
|
|
|
|
|
|
|
config BR2_OPTIMIZE_0
|
|
|
|
|
bool "optimization level 0"
|
|
|
|
|
help
|
2017-10-20 13:19:17 +02:00
|
|
|
Do not optimize.
|
2008-03-12 14:07:10 +01:00
|
|
|
|
|
|
|
|
config BR2_OPTIMIZE_1
|
|
|
|
|
bool "optimization level 1"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Optimize. Optimizing compilation takes somewhat more time, and
|
|
|
|
|
a lot more memory for a large function. With -O, the compiler
|
|
|
|
|
tries to reduce code size and execution time, without
|
|
|
|
|
performing any optimizations that take a great deal of
|
|
|
|
|
compilation time. -O turns on the following optimization
|
2008-08-04 21:07:05 +02:00
|
|
|
flags: -fdefer-pop -fdelayed-branch -fguess-branch-probability
|
|
|
|
|
-fcprop-registers -floop-optimize -fif-conversion
|
|
|
|
|
-fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts
|
|
|
|
|
-ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename
|
2016-05-31 18:57:22 +02:00
|
|
|
-ftree-fre -ftree-ch -funit-at-a-time -fmerge-constants. -O
|
|
|
|
|
also turns on -fomit-frame-pointer on machines where doing so
|
|
|
|
|
does not interfere with debugging.
|
2008-03-12 14:07:10 +01:00
|
|
|
|
|
|
|
|
config BR2_OPTIMIZE_2
|
|
|
|
|
bool "optimization level 2"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Optimize even more. GCC performs nearly all supported
|
|
|
|
|
optimizations that do not involve a space-speed tradeoff. The
|
|
|
|
|
compiler does not perform loop unrolling or function inlining
|
|
|
|
|
when you specify -O2. As compared to -O, this option increases
|
|
|
|
|
both compilation time and the performance of the generated
|
|
|
|
|
code. -O2 turns on all optimization flags specified by -O. It
|
|
|
|
|
also turns on the following optimization flags:
|
|
|
|
|
-fthread-jumps -fcrossjumping -foptimize-sibling-calls
|
2008-08-04 21:07:05 +02:00
|
|
|
-fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm
|
2016-05-31 18:57:22 +02:00
|
|
|
-fexpensive-optimizations -fstrength-reduce
|
|
|
|
|
-frerun-cse-after-loop -frerun-loop-opt -fcaller-saves
|
|
|
|
|
-fpeephole2 -fschedule-insns -fschedule-insns2
|
|
|
|
|
-fsched-interblock -fsched-spec -fregmove -fstrict-aliasing
|
|
|
|
|
-fdelete-null-pointer-checks -freorder-blocks
|
|
|
|
|
-freorder-functions -falign-functions -falign-jumps
|
|
|
|
|
-falign-loops -falign-labels -ftree-vrp -ftree-pre. Please
|
|
|
|
|
note the warning under -fgcse about invoking -O2 on programs
|
2008-03-12 14:07:10 +01:00
|
|
|
that use computed gotos.
|
Config.in: change default optimization level from -Os to -O2
Historically, Buildroot has defaulted to -Os as the gcc optimization
flags. However, this default is probably not the most appropriate
anymore, and this commit therefore changes the default to -O2.
Here are some arguments in favor of this change:
- Most Buildroot users use Buildroot for platforms that have a
reasonable amount of storage, and the difference between -Os and -O2
in terms of code size is no longer as significant compared to the
size of storage available on average embedded Linux devices
typically found these days.
- -Os can have a pretty bad performance impact, compared to -O2.
- -Os is much less widely tested than -O2. For example, with recent
versions of gcc, there are parts of Qt5 that segfault when compiled
with -Os and work perfectly fine with -O2. Yes, it's a compiler bug
that should be fixed, but in the mean time, having a default that's
more widely used/tested makes sense.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2024-01-02 09:36:42 +01:00
|
|
|
This is the default.
|
2008-03-12 14:07:10 +01:00
|
|
|
|
|
|
|
|
config BR2_OPTIMIZE_3
|
|
|
|
|
bool "optimization level 3"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Optimize yet more. -O3 turns on all optimizations specified by
|
|
|
|
|
-O2 and also turns on the -finline-functions, -funswitch-loops
|
|
|
|
|
and -fgcse-after-reload options.
|
2008-03-12 14:07:10 +01:00
|
|
|
|
2016-05-18 23:17:55 +02:00
|
|
|
config BR2_OPTIMIZE_G
|
|
|
|
|
bool "optimize for debugging"
|
|
|
|
|
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
|
|
|
|
|
help
|
|
|
|
|
Optimize for debugging. This enables optimizations that do not
|
2016-05-31 18:57:22 +02:00
|
|
|
interfere with debugging. It should be the optimization level
|
|
|
|
|
of choice for the standard edit-compile-debug cycle, offering
|
|
|
|
|
a reasonable level of optimization while maintaining fast
|
|
|
|
|
compilation and a good debugging experience.
|
2008-03-12 14:07:10 +01:00
|
|
|
|
|
|
|
|
config BR2_OPTIMIZE_S
|
|
|
|
|
bool "optimize for size"
|
|
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Optimize for size. -Os enables all -O2 optimizations that do
|
|
|
|
|
not typically increase code size. It also performs further
|
|
|
|
|
optimizations designed to reduce code size. -Os disables the
|
|
|
|
|
following optimization flags: -falign-functions -falign-jumps
|
|
|
|
|
-falign-loops -falign-labels -freorder-blocks
|
|
|
|
|
-freorder-blocks-and-partition -fprefetch-loop-arrays
|
2008-03-12 14:07:10 +01:00
|
|
|
-ftree-vect-loop-version
|
2008-08-04 21:07:05 +02:00
|
|
|
|
2018-03-26 21:34:05 +02:00
|
|
|
config BR2_OPTIMIZE_FAST
|
2020-07-16 23:44:51 +02:00
|
|
|
bool "optimize for fast (may break packages!)"
|
2018-03-26 21:34:05 +02:00
|
|
|
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_6
|
|
|
|
|
help
|
|
|
|
|
Optimize for fast. Disregard strict standards
|
|
|
|
|
compliance. -Ofast enables all -O3 optimizations. It also
|
|
|
|
|
enables optimizations that are not valid for all
|
2020-07-16 23:44:51 +02:00
|
|
|
standard-compliant programs, so be careful, as it may break
|
|
|
|
|
some packages. It turns on -ffast-math and the
|
2018-03-26 21:34:05 +02:00
|
|
|
Fortran-specific -fstack-arrays, unless -fmax-stack-var-size
|
|
|
|
|
is specified, and -fno-protect-parens.
|
|
|
|
|
|
2008-03-12 14:07:10 +01:00
|
|
|
endchoice
|
2008-03-12 12:23:11 +01:00
|
|
|
|
2022-07-25 17:22:25 +02:00
|
|
|
config BR2_ENABLE_LTO
|
|
|
|
|
bool "build packages with link-time optimisation"
|
|
|
|
|
help
|
|
|
|
|
Enable the link-time optimisation (LTO) option when building
|
|
|
|
|
packages. Link-time optimisation re-runs optimisations at
|
|
|
|
|
link time, which allows the compiler to do interprocedural
|
|
|
|
|
analysis across compilation units and thus come with better
|
|
|
|
|
results: smaller size and better performance.
|
|
|
|
|
|
|
|
|
|
Note that this analysis is limited to statically linked
|
|
|
|
|
object files and libraries.
|
|
|
|
|
|
|
|
|
|
This option may significantly increase build times,
|
|
|
|
|
sometimes 5 times longer, with only limited gains.
|
|
|
|
|
|
|
|
|
|
At this time, this option only enables LTO in packages that
|
|
|
|
|
have an explicit configuration option for it. Other packages
|
|
|
|
|
always enable LTO, but most packages never enable LTO.
|
|
|
|
|
|
2014-07-31 22:08:55 +02:00
|
|
|
config BR2_GOOGLE_BREAKPAD_ENABLE
|
|
|
|
|
bool "Enable google-breakpad support"
|
|
|
|
|
depends on BR2_INSTALL_LIBSTDCPP
|
2024-03-03 14:22:22 +01:00
|
|
|
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_7 # C++17
|
2016-09-15 02:46:29 +02:00
|
|
|
depends on BR2_USE_WCHAR
|
2016-09-19 16:50:46 +02:00
|
|
|
depends on BR2_TOOLCHAIN_HAS_THREADS
|
2023-12-03 05:18:35 +01:00
|
|
|
depends on BR2_TOOLCHAIN_USES_GLIBC
|
2014-07-31 22:08:55 +02:00
|
|
|
depends on BR2_PACKAGE_GOOGLE_BREAKPAD_ARCH_SUPPORTS
|
2017-11-26 15:40:19 +01:00
|
|
|
depends on BR2_PACKAGE_HOST_GOOGLE_BREAKPAD_ARCH_SUPPORTS
|
2018-04-01 07:08:33 +02:00
|
|
|
select BR2_PACKAGE_GOOGLE_BREAKPAD
|
2014-07-31 22:08:55 +02:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
This option will enable the use of google breakpad, a library
|
|
|
|
|
and tool suite that allows you to distribute an application to
|
|
|
|
|
users with compiler-provided debugging information removed,
|
|
|
|
|
record crashes in compact "minidump" files, send them back to
|
|
|
|
|
your server and produce C and C++ stack traces from these
|
|
|
|
|
minidumps. Breakpad can also write minidumps on request for
|
|
|
|
|
programs that have not crashed.
|
2014-07-31 22:08:55 +02:00
|
|
|
|
|
|
|
|
if BR2_GOOGLE_BREAKPAD_ENABLE
|
|
|
|
|
|
|
|
|
|
config BR2_GOOGLE_BREAKPAD_INCLUDE_FILES
|
|
|
|
|
string "List of executables and libraries to extract symbols from"
|
|
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
You may specify a space-separated list of binaries and
|
|
|
|
|
libraries with full paths relative to $(TARGET_DIR) of which
|
|
|
|
|
debug symbols will be dumped for further use with google
|
|
|
|
|
breakpad.
|
|
|
|
|
|
|
|
|
|
A directory structure that can be used by minidump-stackwalk
|
|
|
|
|
will be created at:
|
|
|
|
|
|
|
|
|
|
$(STAGING_DIR)/usr/share/google-breakpad-symbols
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:
1. Build and use static libraries only;
2. Build both shared and static libraries, but use shared libraries;
3. Build and use shared libraries only.
On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.
In addition to the introduction of the Config.in options, this commit
also:
* Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
will be selected when the binary format is BR2_BINFMT_FLAT, since
BR2_STATIC_LIBS will be the only possible solution in the choice.
* Changes package/Makefile.in to use the proper
--{enable,disable}-{shared,static} options for autotools packages.
[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 23:50:09 +01:00
|
|
|
choice
|
|
|
|
|
bool "libraries"
|
2014-12-11 23:50:11 +01:00
|
|
|
default BR2_SHARED_LIBS if BR2_BINFMT_SUPPORTS_SHARED
|
Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:
1. Build and use static libraries only;
2. Build both shared and static libraries, but use shared libraries;
3. Build and use shared libraries only.
On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.
In addition to the introduction of the Config.in options, this commit
also:
* Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
will be selected when the binary format is BR2_BINFMT_FLAT, since
BR2_STATIC_LIBS will be the only possible solution in the choice.
* Changes package/Makefile.in to use the proper
--{enable,disable}-{shared,static} options for autotools packages.
[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 23:50:09 +01:00
|
|
|
default BR2_STATIC_LIBS if !BR2_BINFMT_SUPPORTS_SHARED
|
|
|
|
|
help
|
|
|
|
|
Select the type of libraries you want to use on the target.
|
|
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
The default is to build dynamic libraries and use those on the
|
|
|
|
|
target filesystem, except when the architecture and/or the
|
|
|
|
|
selected binary format does not support shared libraries.
|
Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:
1. Build and use static libraries only;
2. Build both shared and static libraries, but use shared libraries;
3. Build and use shared libraries only.
On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.
In addition to the introduction of the Config.in options, this commit
also:
* Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
will be selected when the binary format is BR2_BINFMT_FLAT, since
BR2_STATIC_LIBS will be the only possible solution in the choice.
* Changes package/Makefile.in to use the proper
--{enable,disable}-{shared,static} options for autotools packages.
[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 23:50:09 +01:00
|
|
|
|
2014-12-03 22:41:29 +01:00
|
|
|
config BR2_STATIC_LIBS
|
Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:
1. Build and use static libraries only;
2. Build both shared and static libraries, but use shared libraries;
3. Build and use shared libraries only.
On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.
In addition to the introduction of the Config.in options, this commit
also:
* Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
will be selected when the binary format is BR2_BINFMT_FLAT, since
BR2_STATIC_LIBS will be the only possible solution in the choice.
* Changes package/Makefile.in to use the proper
--{enable,disable}-{shared,static} options for autotools packages.
[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 23:50:09 +01:00
|
|
|
bool "static only"
|
toolchain: invert glibc <-> !static dependency
Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain
variants.
However, for some architectures, glibc is the only supported libc. In
commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e ("Config.in: only
allow BR2_STATIC_LIBS on supported libc/arch"), we implemented a fix
to avoid configurations were BR2_STATIC_LIBS=y with an architecture
already supported by glibc, because these configurations are
impossible. This commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e
prevents from selecting BR2_STATIC_LIBS=y when the C library used for
the internal toolchain backend is glibc.
However, it introduces a discrepency between how this topic is handled
for internal and external toolchains:
- For internal toolchains, we prevent BR2_STATIC_LIBS=y if glibc is
chosen.
- For external toolchains, we allow BR2_STATIC_LIBS=y in all cases,
and it's each glibc toolchain that has !BR2_STATIC_LIBS
This commit addresses this discrepency by preventing BR2_STATIC_LIBS=y
if glibc is chosen in all cases.
Thanks to this, we can remove the !BR2_STATIC_LIBS dependency on both
the glibc package, and all glibc external toolchains.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=14256
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: update to master, fix the gen-bootlin-toolchains script, add
a comment in the static/shared choice to indicate that static is
supported only with uclibc or musl]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-10-06 22:41:32 +02:00
|
|
|
depends on !BR2_TOOLCHAIN_USES_GLIBC
|
2007-06-02 00:16:28 +02:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
Build and use only static libraries. No shared libraries will
|
2016-07-31 18:02:47 +02:00
|
|
|
be installed on the target. This potentially increases your
|
2016-05-31 18:57:22 +02:00
|
|
|
code size and should only be used if you know what you are
|
|
|
|
|
doing. Note that some packages may not be available when this
|
|
|
|
|
option is enabled, due to their need for dynamic library
|
|
|
|
|
support.
|
2007-06-02 00:16:28 +02:00
|
|
|
|
toolchain: invert glibc <-> !static dependency
Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain
variants.
However, for some architectures, glibc is the only supported libc. In
commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e ("Config.in: only
allow BR2_STATIC_LIBS on supported libc/arch"), we implemented a fix
to avoid configurations were BR2_STATIC_LIBS=y with an architecture
already supported by glibc, because these configurations are
impossible. This commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e
prevents from selecting BR2_STATIC_LIBS=y when the C library used for
the internal toolchain backend is glibc.
However, it introduces a discrepency between how this topic is handled
for internal and external toolchains:
- For internal toolchains, we prevent BR2_STATIC_LIBS=y if glibc is
chosen.
- For external toolchains, we allow BR2_STATIC_LIBS=y in all cases,
and it's each glibc toolchain that has !BR2_STATIC_LIBS
This commit addresses this discrepency by preventing BR2_STATIC_LIBS=y
if glibc is chosen in all cases.
Thanks to this, we can remove the !BR2_STATIC_LIBS dependency on both
the glibc package, and all glibc external toolchains.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=14256
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: update to master, fix the gen-bootlin-toolchains script, add
a comment in the static/shared choice to indicate that static is
supported only with uclibc or musl]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-10-06 22:41:32 +02:00
|
|
|
comment "static only needs a toolchain w/ uclibc or musl"
|
|
|
|
|
depends on BR2_TOOLCHAIN_USES_GLIBC
|
|
|
|
|
|
Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:
1. Build and use static libraries only;
2. Build both shared and static libraries, but use shared libraries;
3. Build and use shared libraries only.
On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.
In addition to the introduction of the Config.in options, this commit
also:
* Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
will be selected when the binary format is BR2_BINFMT_FLAT, since
BR2_STATIC_LIBS will be the only possible solution in the choice.
* Changes package/Makefile.in to use the proper
--{enable,disable}-{shared,static} options for autotools packages.
[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 23:50:09 +01:00
|
|
|
config BR2_SHARED_LIBS
|
|
|
|
|
bool "shared only"
|
|
|
|
|
depends on BR2_BINFMT_SUPPORTS_SHARED
|
|
|
|
|
help
|
|
|
|
|
Build and use only shared libraries. This is the recommended
|
|
|
|
|
solution as it saves space and build time.
|
|
|
|
|
|
|
|
|
|
config BR2_SHARED_STATIC_LIBS
|
|
|
|
|
bool "both static and shared"
|
|
|
|
|
depends on BR2_BINFMT_SUPPORTS_SHARED
|
|
|
|
|
help
|
|
|
|
|
Build both shared and static libraries, but link executables
|
|
|
|
|
dynamically. While building both shared and static libraries
|
|
|
|
|
take more time and more disk space, having static libraries
|
|
|
|
|
may be useful to link some of the applications statically.
|
2014-10-12 18:34:44 +02:00
|
|
|
|
Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:
1. Build and use static libraries only;
2. Build both shared and static libraries, but use shared libraries;
3. Build and use shared libraries only.
On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.
In addition to the introduction of the Config.in options, this commit
also:
* Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
will be selected when the binary format is BR2_BINFMT_FLAT, since
BR2_STATIC_LIBS will be the only possible solution in the choice.
* Changes package/Makefile.in to use the proper
--{enable,disable}-{shared,static} options for autotools packages.
[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 23:50:09 +01:00
|
|
|
endchoice
|
2014-10-12 18:34:44 +02:00
|
|
|
|
2011-09-29 21:57:38 +02:00
|
|
|
config BR2_PACKAGE_OVERRIDE_FILE
|
|
|
|
|
string "location of a package override file"
|
2014-01-29 22:48:24 +01:00
|
|
|
default "$(CONFIG_DIR)/local.mk"
|
2011-09-29 21:57:38 +02:00
|
|
|
help
|
|
|
|
|
A package override file is a short makefile that contains
|
2016-05-31 18:57:22 +02:00
|
|
|
variable definitions of the form <pkg>_OVERRIDE_SRCDIR, which
|
|
|
|
|
allows to tell Buildroot to use an existing directory as the
|
|
|
|
|
source directory for a particular package. See the Buildroot
|
|
|
|
|
documentation for more details on this feature.
|
2011-09-29 21:57:38 +02:00
|
|
|
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
config BR2_GLOBAL_PATCH_DIR
|
package/pkg-download: lookup hash files in global-patch-dir
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:13 +01:00
|
|
|
string "global patch and hash directories"
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
help
|
2016-05-31 18:57:22 +02:00
|
|
|
You may specify a space separated list of one or more
|
package/pkg-download: lookup hash files in global-patch-dir
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:13 +01:00
|
|
|
directories containing global package patches and/or hashes.
|
|
|
|
|
For a specific version <packageversion> of a specific package
|
|
|
|
|
<packagename>, patches are looked up as follows:
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
First, the default Buildroot patch set for the package is
|
|
|
|
|
applied from the package's directory in Buildroot.
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
2013-12-18 11:25:01 +01:00
|
|
|
Then for every directory - <global-patch-dir> - that exists in
|
|
|
|
|
BR2_GLOBAL_PATCH_DIR, if the directory
|
2016-05-31 18:57:22 +02:00
|
|
|
<global-patch-dir>/<packagename>/<packageversion>/ exists,
|
|
|
|
|
then all *.patch files in this directory will be applied.
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
2016-05-31 18:57:22 +02:00
|
|
|
Otherwise, if the directory <global-patch-dir>/<packagename>
|
|
|
|
|
exists, then all *.patch files in the directory will be
|
|
|
|
|
applied.
|
rework patch model
At the Buildroot Developers Meeting (4-5 February 2013, in Brussels) a change
to the patch logic was discussed. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013
for details. In summary:
* For patches stored in the package directory, if
package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch,
otherwise, apply package/<pkg>/*.patch
* For patches stored in the global patches directory, if
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply
$(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply
$(GLOBAL_PATCH_DIR)/<pkg>/*.patch
This patch adds the new BR2_GLOBAL_PATCH_DIR configuration item, and reworks
the generic package infrastructure to implement the new patch logic.
[Peter: fixup doc nits as pointed out by Thomas]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-18 00:13:47 +01:00
|
|
|
|
package/pkg-download: lookup hash files in global-patch-dir
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:13 +01:00
|
|
|
The hash files are looked up similarly to the patches.
|
|
|
|
|
|
2014-12-10 23:53:57 +01:00
|
|
|
menu "Advanced"
|
|
|
|
|
|
2018-11-27 05:10:09 +01:00
|
|
|
config BR2_FORCE_HOST_BUILD
|
|
|
|
|
bool "Force the building of host dependencies"
|
|
|
|
|
help
|
|
|
|
|
Build all available host dependencies, even if they are
|
|
|
|
|
already installed on the system.
|
|
|
|
|
|
|
|
|
|
This option can be used to ensure that the download cache of
|
|
|
|
|
source archives for packages remain consistent between
|
|
|
|
|
different build hosts.
|
|
|
|
|
|
|
|
|
|
This option will increase build time.
|
|
|
|
|
|
2023-11-06 20:09:14 +01:00
|
|
|
config BR2_DOWNLOAD_FORCE_CHECK_HASHES
|
|
|
|
|
bool "Force all downloads to have a valid hash"
|
|
|
|
|
help
|
|
|
|
|
Say 'y' here to enforce downloads to have at least one valid
|
|
|
|
|
hash (and of course, that all hashes be valid).
|
|
|
|
|
|
2023-12-27 18:07:58 +01:00
|
|
|
By default, Buildroot checks hashes of all packages
|
|
|
|
|
downloaded, except those for which a custom version is
|
|
|
|
|
used.
|
2023-11-06 20:09:14 +01:00
|
|
|
|
2023-12-27 18:07:58 +01:00
|
|
|
With this option turned on, Buildroot will check hashes of
|
|
|
|
|
all packages, including those that use a custom version. In
|
|
|
|
|
order to provide hashes for such packages, place additional
|
|
|
|
|
hash files in BR2_GLOBAL_PATCH_DIR directories.
|
2023-11-06 20:09:14 +01:00
|
|
|
|
2016-06-14 17:31:09 +02:00
|
|
|
config BR2_REPRODUCIBLE
|
|
|
|
|
bool "Make the build reproducible (experimental)"
|
toolchain/wrapper: fake __DATE_ and __TIME__ for older gcc
Starting with version 7, gcc automatically recognises and enforces the
environment variable SOURCE_DATE_EPOCH, and fakes __DATE__ and __TIME__
accordingly, to produce reproducible builds (at least in regards to date
and time).
However, older gcc versions do not offer this feature.
So, we use our toolchain wrapper to force-feed __DATE__ and __TIME__ as
macros, which will take precedence over those that gcc may compute
itself. We compute them according to the specs:
https://reproducible-builds.org/specs/source-date-epoch/
https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
Since we define macros otherwise internal to gcc, we have to tell it not
to warn about that. The -Wno-builtin-macro-redefined flag was introduced
in gcc-4.4.0. Therefore, we make BR2_REPRODUCIBLE depend on GCC >= 4.4.
gcc-7 will ignore SOURCE_DATE_EPOCH when __DATE__ and __TIME__ are
user-defined. Anyway, this is of no consequence: whether __DATE__ and
__TIME__ or SOURCE_DATE_EPOCH takes precedence, it would yield the
exact same end result since we use the same logic to compute it. Note
that we didn't copy the code for it from gcc so using the same logic
doesn't imply that we're inheriting GPL-3.0.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jérôme Pouiller <jezz@sysmic.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
[Arnout: rewrite commit message]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-10-21 22:31:02 +02:00
|
|
|
# SOURCE_DATE_EPOCH support in toolchain-wrapper requires GCC 4.4
|
|
|
|
|
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_4
|
2016-07-02 17:06:18 +02:00
|
|
|
help
|
|
|
|
|
This option will remove all sources of non-reproducibility
|
|
|
|
|
from the build process. For a given Buildroot configuration,
|
|
|
|
|
this allows to generate exactly identical binaries from one
|
|
|
|
|
build to the other, including on different machines.
|
|
|
|
|
|
2016-11-23 13:58:56 +01:00
|
|
|
The current implementation is restricted to builds with the
|
|
|
|
|
same output directory. Many (absolute) paths are recorded in
|
|
|
|
|
intermediary files, and it is very likely that some of these
|
|
|
|
|
paths leak into the target rootfs. If you build with the
|
|
|
|
|
same O=... path, however, the result is identical.
|
|
|
|
|
|
2016-07-02 17:06:18 +02:00
|
|
|
This is labeled as an experimental feature, as not all
|
|
|
|
|
packages behave properly to ensure reproducibility.
|
2016-06-14 17:31:09 +02:00
|
|
|
|
core: implement per-package SDK and target
This commit implements the core of the move to per-package SDK and
target directories. The main idea is that instead of having a global
output/host and output/target in which all packages install files, we
switch to per-package host and target directories, that only contain
their explicit dependencies.
There are two main benefits:
- Packages will now see only the dependencies they explicitly list in
their <pkg>_DEPENDENCIES variable, and the recursive dependencies
thereof.
- We can support top-level parallel build properly, because a package
only "sees" its own host directory and target directory, isolated
from the build of other packages that can happen in parallel.
It works as follows:
- A new output/per-package/ directory is created, which will contain
one sub-directory per package, and inside it, a "host" directory
and a "target" directory:
output/per-package/busybox/target
output/per-package/busybox/host
output/per-package/host-fakeroot/target
output/per-package/host-fakeroot/host
This output/per-package/ directory is PER_PACKAGE_DIR.
- The global TARGET_DIR and HOST_DIR variable now automatically point
to the per-package directory when PKG is defined. So whenever a
package references $(HOST_DIR) or $(TARGET_DIR) in its build
process, it effectively references the per-package host/target
directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it
is handled as well.
- Of course, packages have dependencies, so those dependencies must
be installed in the per-package host and target directories. To do
so, we simply rsync (using hard links to save space and time) the
host and target directories of the direct dependencies of the
package to the current package host and target directories.
We only need to take care of direct dependencies (and not
recursively all dependencies), because we accumulate into those
per-package host and target directories the files installed by the
dependencies. Note that this only works because we make the
assumption that one package does *not* overwrite files installed by
another package.
This is done for "extract dependencies" at the beginning of the
extract step, and for "normal dependencies" at the beginning of the
configure step.
This is basically enough to make per-package SDK and target work. The
only gotcha is that at the end of the build, output/target and
output/host are empty, which means that:
- The filesystem image creation code cannot work.
- We don't have a SDK to build code outside of Buildroot.
In order to fix this, this commit extends the target-finalize step so
that it starts by populating output/target and output/host by
rsync-ing into them the target and host directories of all packages
listed in the $(PACKAGES) variable. It is necessary to do this
sequentially in the target-finalize step and not in each
package. Doing it in package installation means that it can be done in
parallel. In that case, there is a chance that two rsyncs are creating
the same hardlink or directory at the same time, which makes one of
them fail.
This change to per-package directories has an impact on the RPATH
built into the host binaries, as those RPATH now point to various
per-package host directories, and no longer to the global host
directory. We do not try to rewrite such RPATHs during the build as
having such RPATHs is perfectly fine, but we still need to handle two
fallouts from this change:
- The check-host-rpath script, which verifies at the end of each
package installation that it has the appropriate RPATH, is modified
to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is
a correct RPAT.
- The fix-rpath script, which mungles the RPATH mainly for the SDK
preparation, is modified to rewrite the RPATH to not point to
per-package directories. Indeed the patchelf --make-rpath-relative
call only works if the RPATH points to the ROOTDIR passed as
argument, and this ROOTDIR is the global host directory. Rewriting
the RPATH to not point to per-package host directories prior to
this is an easy solution to this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
|
|
|
config BR2_PER_PACKAGE_DIRECTORIES
|
|
|
|
|
bool "Use per-package directories (experimental)"
|
|
|
|
|
help
|
|
|
|
|
This option will change the build process of Buildroot
|
|
|
|
|
package to use per-package target and host directories.
|
|
|
|
|
|
|
|
|
|
This is useful for two related purposes:
|
|
|
|
|
|
|
|
|
|
- Cleanly isolate the build of each package, so that a
|
|
|
|
|
given package only "sees" the dependencies it has
|
|
|
|
|
explicitly expressed, and not other packages that may
|
|
|
|
|
have by chance been built before.
|
|
|
|
|
|
|
|
|
|
- Enable top-level parallel build.
|
|
|
|
|
|
|
|
|
|
This is labeled as an experimental feature, as not all
|
|
|
|
|
packages behave properly with per-package directories.
|
|
|
|
|
|
2004-12-11 14:01:10 +01:00
|
|
|
endmenu
|
2004-10-09 03:06:03 +02:00
|
|
|
|
Config.in: introduce BR2_TIME_BITS_64 option for Y2038 compatibility
Y2038 is now almost only 15 years away, and embedded systems built
today are potentially going to still be operational in 15 years, and
even though they are supposed to receive updates by then, we all know
how things go, and potentially some of these embedded systems will not
receive any update.
In 2038, the signed 32-bit representation of time_t used on 32-bit
architectures will overflow, causing all time-related functions to go
back in time in a surprising way.
The Linux kernel has already been modified to support a 64-bit
representation of time_t on 32-bit architectures, but from a C library
perspective, the situation varies:
- glibc uses this 64-bit time_t representation on 32-bit systems
since glibc 2.34, but only if -D_TIME_BITS=64 is
specified. Therefore, this commit adds an option to add this flag
globally to the build, when glibc is the C library and the
architecture is not 64-bit.
- musl uses unconditionally a 64-bit time_t representation on 32-bit
systems since musl 1.2.0. So there is nothing to do here since
Buildroot has been using a musl >= 1.2.0, used since Buildroot
2020.05. No Buildroot option is needed here.
- uClibc-ng does not support a 64-bit time_t representation on 32-bit
systems, so systems using uClibc-ng will not be Y2038 compliant, at
least for now. No Buildroot option is needed here.
It should be noted that being Y2038-compliant will only work if all
application/library code is correct. For example if an
application/library stores a timestamp in an "int" instead of using
the proper time_t type, then the mechanisms described above will not
fix this, and the application/library will continue to be broken in
terms of Y2038 support.
Possible discussions points about this patch:
- Should we have an option at all, or should we unconditionally pass
-D_TIME_BITS=64, like we have been doing for _FILE_OFFSET_BITS=64
for quite some time. The reasoning for having an option is that
the mechanism is itself opt-in in glibc, and generally relatively
new, so it seemed logical for now to make it optional as well in
Buildroot.
- Should we show something (a Config.in comment?) in the musl and
uClibc-ng case to let the user know that the code is Y2038
compliant (musl) or not Y2038 compliant (uClibc-ng). Or should this
discussion be part of the Buildroot documentation?
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-10-12 23:50:08 +02:00
|
|
|
config BR2_TIME_BITS_64
|
|
|
|
|
bool "Build Y2038-ready code"
|
|
|
|
|
depends on BR2_TOOLCHAIN_USES_GLIBC && !BR2_ARCH_IS_64
|
|
|
|
|
help
|
|
|
|
|
This option will pass -D_TIME_BITS=64 in the compiler flags
|
|
|
|
|
to ensure the glibc C library uses a 64-bit representation
|
|
|
|
|
for time_t and other time types, which ensures that
|
|
|
|
|
programs/libraries will correctly handle time past year
|
|
|
|
|
2038.
|
|
|
|
|
|
|
|
|
|
This option only has an effect with glibc >= 2.34, as
|
|
|
|
|
earlier glibc versions did not have support for 64-bit
|
|
|
|
|
time_t.
|
|
|
|
|
|
2018-01-24 05:09:40 +01:00
|
|
|
comment "Security Hardening Options"
|
|
|
|
|
|
2021-07-25 15:45:19 +02:00
|
|
|
config BR2_PIC_PIE_ARCH_SUPPORTS
|
|
|
|
|
bool
|
Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default
Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
default.
For SSP, SSP-all can have a significant impact on performance, so we do
not want to enable that unconditionally; instead we use SSP-strong if
available (since gcc-4.9), and resort to SSP-regular otherwise. People
who really, like really-really want to use SSP-all will still have to
enable it explicitly.
For FORTIFY, level 2 may change the behaviour of some glibc functions,
so may crash conforming programs, so may have adverse effects. As such,
we choose level 1 as the default, as it does not change the behaviour
of any function.
This could help making IoT more secure and fight against the assumption
that buildroot does not support binary hardening (see
https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- relax SSP to strong when available, regular otherwise
- extend commit log to explain why SSP-all is not used
- extend commit log to explain why FORTIFY level 2 is not used
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-05-03 20:22:41 +02:00
|
|
|
default y
|
2021-06-12 12:24:49 +02:00
|
|
|
# Microblaze glibc toolchains don't work with PIC/PIE enabled
|
|
|
|
|
depends on !BR2_microblaze
|
2021-06-01 21:00:21 +02:00
|
|
|
# Nios2 toolchains produce non working binaries with -fPIC
|
|
|
|
|
depends on !BR2_nios2
|
2021-07-25 15:45:19 +02:00
|
|
|
|
|
|
|
|
config BR2_PIC_PIE
|
|
|
|
|
bool "Build code with PIC/PIE"
|
|
|
|
|
default y
|
|
|
|
|
depends on BR2_PIC_PIE_ARCH_SUPPORTS
|
2019-03-12 13:09:36 +01:00
|
|
|
depends on BR2_SHARED_LIBS
|
2019-10-27 23:03:34 +01:00
|
|
|
depends on BR2_TOOLCHAIN_SUPPORTS_PIE
|
2019-03-12 13:09:36 +01:00
|
|
|
help
|
|
|
|
|
Generate Position-Independent Code (PIC) and link
|
|
|
|
|
Position-Independent Executables (PIE).
|
|
|
|
|
|
2019-10-27 23:03:34 +01:00
|
|
|
comment "PIC/PIE needs a toolchain w/ PIE"
|
2021-07-25 15:45:19 +02:00
|
|
|
depends on BR2_PIC_PIE_ARCH_SUPPORTS
|
2019-10-27 23:03:34 +01:00
|
|
|
depends on BR2_SHARED_LIBS
|
|
|
|
|
depends on !BR2_TOOLCHAIN_SUPPORTS_PIE
|
|
|
|
|
|
2018-01-24 05:09:40 +01:00
|
|
|
choice
|
|
|
|
|
bool "Stack Smashing Protection"
|
2021-05-04 22:09:11 +02:00
|
|
|
default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
|
Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default
Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
default.
For SSP, SSP-all can have a significant impact on performance, so we do
not want to enable that unconditionally; instead we use SSP-strong if
available (since gcc-4.9), and resort to SSP-regular otherwise. People
who really, like really-really want to use SSP-all will still have to
enable it explicitly.
For FORTIFY, level 2 may change the behaviour of some glibc functions,
so may crash conforming programs, so may have adverse effects. As such,
we choose level 1 as the default, as it does not change the behaviour
of any function.
This could help making IoT more secure and fight against the assumption
that buildroot does not support binary hardening (see
https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- relax SSP to strong when available, regular otherwise
- extend commit log to explain why SSP-all is not used
- extend commit log to explain why FORTIFY level 2 is not used
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-05-03 20:22:41 +02:00
|
|
|
default BR2_SSP_STRONG if BR2_TOOLCHAIN_HAS_SSP_STRONG
|
|
|
|
|
default BR2_SSP_REGULAR
|
2018-01-24 05:09:40 +01:00
|
|
|
depends on BR2_TOOLCHAIN_HAS_SSP
|
|
|
|
|
help
|
|
|
|
|
Enable stack smashing protection support using GCC's
|
|
|
|
|
-fstack-protector option family.
|
|
|
|
|
|
|
|
|
|
See
|
|
|
|
|
http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt
|
|
|
|
|
for details.
|
|
|
|
|
|
|
|
|
|
Note that this requires the toolchain to have SSP support.
|
|
|
|
|
This is always the case for glibc and eglibc toolchain, but is
|
|
|
|
|
optional in uClibc toolchains.
|
|
|
|
|
|
|
|
|
|
config BR2_SSP_NONE
|
|
|
|
|
bool "None"
|
|
|
|
|
help
|
|
|
|
|
Disable stack-smashing protection.
|
|
|
|
|
|
|
|
|
|
config BR2_SSP_REGULAR
|
|
|
|
|
bool "-fstack-protector"
|
|
|
|
|
help
|
|
|
|
|
Emit extra code to check for buffer overflows, such as stack
|
|
|
|
|
smashing attacks. This is done by adding a guard variable to
|
|
|
|
|
functions with vulnerable objects. This includes functions
|
|
|
|
|
that call alloca, and functions with buffers larger than 8
|
|
|
|
|
bytes. The guards are initialized when a function is entered
|
|
|
|
|
and then checked when the function exits. If a guard check
|
|
|
|
|
fails, an error message is printed and the program exits.
|
|
|
|
|
|
|
|
|
|
config BR2_SSP_STRONG
|
|
|
|
|
bool "-fstack-protector-strong"
|
2020-02-20 03:01:16 +01:00
|
|
|
depends on BR2_TOOLCHAIN_HAS_SSP_STRONG
|
2018-01-24 05:09:40 +01:00
|
|
|
help
|
|
|
|
|
Like -fstack-protector but includes additional functions to be
|
|
|
|
|
protected - those that have local array definitions, or have
|
|
|
|
|
references to local frame addresses.
|
|
|
|
|
|
2019-03-12 13:09:35 +01:00
|
|
|
-fstack-protector-strong officially appeared in gcc 4.9, but
|
|
|
|
|
some vendors have backported -fstack-protector-strong to older
|
|
|
|
|
versions of gcc.
|
2018-01-24 05:09:40 +01:00
|
|
|
|
|
|
|
|
config BR2_SSP_ALL
|
|
|
|
|
bool "-fstack-protector-all"
|
|
|
|
|
help
|
|
|
|
|
Like -fstack-protector except that all functions are
|
|
|
|
|
protected. This option might have a significant performance
|
|
|
|
|
impact on the compiled binaries.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2019-03-12 13:09:33 +01:00
|
|
|
config BR2_SSP_OPTION
|
|
|
|
|
string
|
|
|
|
|
default "-fstack-protector" if BR2_SSP_REGULAR
|
|
|
|
|
default "-fstack-protector-strong" if BR2_SSP_STRONG
|
|
|
|
|
default "-fstack-protector-all" if BR2_SSP_ALL
|
|
|
|
|
|
2018-01-24 05:09:40 +01:00
|
|
|
comment "Stack Smashing Protection needs a toolchain w/ SSP"
|
|
|
|
|
depends on !BR2_TOOLCHAIN_HAS_SSP
|
|
|
|
|
|
2018-01-24 05:09:41 +01:00
|
|
|
choice
|
|
|
|
|
bool "RELRO Protection"
|
Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default
Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
default.
For SSP, SSP-all can have a significant impact on performance, so we do
not want to enable that unconditionally; instead we use SSP-strong if
available (since gcc-4.9), and resort to SSP-regular otherwise. People
who really, like really-really want to use SSP-all will still have to
enable it explicitly.
For FORTIFY, level 2 may change the behaviour of some glibc functions,
so may crash conforming programs, so may have adverse effects. As such,
we choose level 1 as the default, as it does not change the behaviour
of any function.
This could help making IoT more secure and fight against the assumption
that buildroot does not support binary hardening (see
https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- relax SSP to strong when available, regular otherwise
- extend commit log to explain why SSP-all is not used
- extend commit log to explain why FORTIFY level 2 is not used
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-05-03 20:22:41 +02:00
|
|
|
default BR2_RELRO_FULL if BR2_TOOLCHAIN_SUPPORTS_PIE
|
|
|
|
|
default BR2_RELRO_PARTIAL
|
2018-01-24 05:09:41 +01:00
|
|
|
depends on BR2_SHARED_LIBS
|
|
|
|
|
help
|
2018-04-01 07:08:39 +02:00
|
|
|
Enable a link-time protection know as RELRO (RELocation Read
|
|
|
|
|
Only) which helps to protect from certain type of exploitation
|
|
|
|
|
techniques altering the content of some ELF sections.
|
2018-01-24 05:09:41 +01:00
|
|
|
|
|
|
|
|
config BR2_RELRO_NONE
|
|
|
|
|
bool "None"
|
|
|
|
|
help
|
|
|
|
|
Disables Relocation link-time protections.
|
|
|
|
|
|
|
|
|
|
config BR2_RELRO_PARTIAL
|
|
|
|
|
bool "Partial"
|
|
|
|
|
help
|
|
|
|
|
This option makes the dynamic section not writeable after
|
|
|
|
|
initialization (with almost no performance penalty).
|
|
|
|
|
|
|
|
|
|
config BR2_RELRO_FULL
|
|
|
|
|
bool "Full"
|
2021-07-25 15:45:19 +02:00
|
|
|
depends on BR2_PIC_PIE_ARCH_SUPPORTS
|
2019-10-27 23:03:34 +01:00
|
|
|
depends on BR2_TOOLCHAIN_SUPPORTS_PIE
|
2019-03-12 13:09:36 +01:00
|
|
|
select BR2_PIC_PIE
|
2018-01-24 05:09:41 +01:00
|
|
|
help
|
2018-04-01 07:08:39 +02:00
|
|
|
This option includes the partial configuration, but also marks
|
|
|
|
|
the GOT as read-only at the cost of initialization time during
|
|
|
|
|
program loading, i.e every time an executable is started.
|
2018-01-24 05:09:41 +01:00
|
|
|
|
2019-10-27 23:03:34 +01:00
|
|
|
comment "RELRO Full needs a toolchain w/ PIE"
|
2021-07-25 15:45:19 +02:00
|
|
|
depends on BR2_PIC_PIE_ARCH_SUPPORTS
|
2019-10-27 23:03:34 +01:00
|
|
|
depends on !BR2_TOOLCHAIN_SUPPORTS_PIE
|
|
|
|
|
|
2018-01-24 05:09:41 +01:00
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
comment "RELocation Read Only (RELRO) needs shared libraries"
|
|
|
|
|
depends on !BR2_SHARED_LIBS
|
|
|
|
|
|
2021-08-21 00:53:41 +02:00
|
|
|
config BR2_FORTIFY_SOURCE_ARCH_SUPPORTS
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
# Microblaze glibc toolchains don't work with Fortify Source enabled
|
|
|
|
|
depends on !BR2_microblaze
|
|
|
|
|
|
2018-01-24 05:09:41 +01:00
|
|
|
choice
|
|
|
|
|
bool "Buffer-overflow Detection (FORTIFY_SOURCE)"
|
Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default
Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
default.
For SSP, SSP-all can have a significant impact on performance, so we do
not want to enable that unconditionally; instead we use SSP-strong if
available (since gcc-4.9), and resort to SSP-regular otherwise. People
who really, like really-really want to use SSP-all will still have to
enable it explicitly.
For FORTIFY, level 2 may change the behaviour of some glibc functions,
so may crash conforming programs, so may have adverse effects. As such,
we choose level 1 as the default, as it does not change the behaviour
of any function.
This could help making IoT more secure and fight against the assumption
that buildroot does not support binary hardening (see
https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- relax SSP to strong when available, regular otherwise
- extend commit log to explain why SSP-all is not used
- extend commit log to explain why FORTIFY level 2 is not used
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-05-03 20:22:41 +02:00
|
|
|
default BR2_FORTIFY_SOURCE_1
|
2021-08-21 00:53:41 +02:00
|
|
|
depends on BR2_FORTIFY_SOURCE_ARCH_SUPPORTS
|
2018-01-24 05:09:41 +01:00
|
|
|
depends on BR2_TOOLCHAIN_USES_GLIBC
|
|
|
|
|
depends on !BR2_OPTIMIZE_0
|
|
|
|
|
help
|
|
|
|
|
Enable the _FORTIFY_SOURCE macro which introduces additional
|
2018-04-01 07:08:39 +02:00
|
|
|
checks to detect buffer-overflows in the following standard
|
|
|
|
|
library functions: memcpy, mempcpy, memmove, memset, strcpy,
|
|
|
|
|
stpcpy, strncpy, strcat, strncat, sprintf, vsprintf, snprintf,
|
|
|
|
|
vsnprintf, gets.
|
2018-01-24 05:09:41 +01:00
|
|
|
|
|
|
|
|
NOTE: This feature requires an optimization level of s/1/2/3/g
|
|
|
|
|
|
|
|
|
|
Support for this feature has been present since GCC 4.x.
|
|
|
|
|
|
|
|
|
|
config BR2_FORTIFY_SOURCE_NONE
|
|
|
|
|
bool "None"
|
|
|
|
|
help
|
|
|
|
|
Disables additional checks to detect buffer-overflows.
|
|
|
|
|
|
|
|
|
|
config BR2_FORTIFY_SOURCE_1
|
|
|
|
|
bool "Conservative"
|
2018-11-05 21:07:50 +01:00
|
|
|
# gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164
|
|
|
|
|
depends on !BR2_TOOLCHAIN_BUILDROOT || BR2_TOOLCHAIN_GCC_AT_LEAST_6
|
2018-01-24 05:09:41 +01:00
|
|
|
help
|
|
|
|
|
This option sets _FORTIFY_SOURCE to 1 and only introduces
|
|
|
|
|
checks that shouldn't change the behavior of conforming
|
|
|
|
|
programs. Adds checks at compile-time only.
|
|
|
|
|
|
|
|
|
|
config BR2_FORTIFY_SOURCE_2
|
|
|
|
|
bool "Aggressive"
|
2018-11-05 21:07:50 +01:00
|
|
|
# gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164
|
|
|
|
|
depends on !BR2_TOOLCHAIN_BUILDROOT || BR2_TOOLCHAIN_GCC_AT_LEAST_6
|
2018-01-24 05:09:41 +01:00
|
|
|
help
|
|
|
|
|
This option sets _FORTIFY_SOURCES to 2 and some more
|
|
|
|
|
checking is added, but some conforming programs might fail.
|
|
|
|
|
Also adds checks at run-time (detected buffer overflow
|
|
|
|
|
terminates the program)
|
|
|
|
|
|
2022-09-18 23:21:44 +02:00
|
|
|
config BR2_FORTIFY_SOURCE_3
|
|
|
|
|
bool "Extended"
|
|
|
|
|
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_12
|
|
|
|
|
help
|
|
|
|
|
This option sets _FORTIFY_SOURCES to 3 and even more
|
|
|
|
|
checking is added compared to level 2. Extends checks at
|
|
|
|
|
run-time that can introduce an additional performance
|
|
|
|
|
overhead.
|
|
|
|
|
|
2018-01-24 05:09:41 +01:00
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
comment "Fortify Source needs a glibc toolchain and optimization"
|
2021-08-21 00:53:41 +02:00
|
|
|
depends on BR2_FORTIFY_SOURCE_ARCH_SUPPORTS
|
2018-01-24 05:09:41 +01:00
|
|
|
depends on (!BR2_TOOLCHAIN_USES_GLIBC || BR2_OPTIMIZE_0)
|
2016-08-25 19:19:46 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2012-11-03 09:27:58 +01:00
|
|
|
source "system/Config.in"
|
2010-12-05 21:52:44 +01:00
|
|
|
|
2013-08-17 22:35:37 +02:00
|
|
|
source "linux/Config.in"
|
2007-09-25 09:55:45 +02:00
|
|
|
|
2013-08-17 22:35:37 +02:00
|
|
|
source "package/Config.in"
|
2012-01-28 18:42:49 +01:00
|
|
|
|
2010-03-10 22:30:06 +01:00
|
|
|
source "fs/Config.in"
|
|
|
|
|
|
2010-03-14 18:20:45 +01:00
|
|
|
source "boot/Config.in"
|
|
|
|
|
|
2013-08-17 22:35:37 +02:00
|
|
|
source "package/Config.in.host"
|
2012-11-12 11:08:28 +01:00
|
|
|
|
|
|
|
|
source "Config.in.legacy"
|
2013-12-05 20:11:11 +01:00
|
|
|
|
2019-07-29 22:19:59 +02:00
|
|
|
# br2-external menus definitions
|
|
|
|
|
source "$BR2_BASE_DIR/.br2-external.in.menus"
|
