crosstool-ng/config/libc/glibc-eglibc.in-common
Yann E. MORIN" f603742014 libc/glibc: use the multi-inclusion capability of the new kconfig
Now that kconfig can include a file multiple times, link the glibc/eglibc
common stuff to two .in.2 files.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-05-09 20:15:39 +02:00

246 lines
8.2 KiB
Plaintext

# This file contains the common configuration options
# that apply to both glibc and eglibc.
# Some architectures require the ports addon. List them one by one here:
# This list must be carefully in sync with the architectures names
# we can find in config/arch/*
config LIBC_GLIBC_MAY_FORCE_PORTS
bool
default y if ARCH_arm
default y if ARCH_mips
select LIBC_GLIBC_USE_PORTS
# Force using the BFD linker during the toolchain build
config LIBC_glibc_familly
bool
default y
select BINUTILS_FORCE_LD_BFD
config LIBC_GLIBC_EXTRA_CONFIG
string
prompt "extra config"
default ""
help
Extra flags to pass onto ./configure when configuring.
Eg.: --enable-static-nss
config LIBC_GLIBC_CONFIGPARMS
string
prompt "Extra config params (READ HELP)"
default "" if ! ARCH_sh
default "no-z-defs=yes" if ARCH_sh
help
Some architectures need to set options in the file configparms.
This is the case for sh3/4, which really need to set configparms
to "no-z-defs=yes" as of gcc-3.4/glibc-2.3.2.
Unless you are building a toolchain for sh3/4, you should leave that empty.
Note: If you need to pass more than one value, separate them with
'\n'. Eg.: var1=val1\nvar2=val2
config LIBC_GLIBC_EXTRA_CFLAGS
string
prompt "extra target CFLAGS"
default ""
help
Extra target CFLAGS to use when building.
config LIBC_EXTRA_CC_ARGS
string
prompt "gcc extra flags"
default ""
help
Extra flags to pass gcc when building.
Seldom used, except for sparc64 which seems to need the flag -64
to be passed onto gcc.
config LIBC_ENABLE_FORTIFIED_BUILD
bool
prompt "Enable fortified build (EXPERIMENTAL)"
depends on EXPERIMENTAL
default n
help
If you say 'y' here, then glibc will be using fortified versions
of functions with format arguments (eg. vsyslog, printf...), and
do a sanity check on the format at runtime, to avoid some of the
common format string attacks.
This is currently not supported, and will most probably result in
a broken build, with an error message like:
../misc/syslog.c: In function '__vsyslog_chk':
../misc/syslog.c:123: sorry, unimplemented: inlining failed in
call to 'syslog': function body not available
If you are brave enough and want to debug the issue, then say 'y'
here. Otherwise, be still and say 'n' (the default). ;-)
config LIBC_DISABLE_VERSIONING
bool
prompt "Disable symbols versioning"
default n
help
Do not include versioning information in the library objects.
config LIBC_OLDEST_ABI
string
prompt "Oldest supported ABI"
default ""
help
Set the oldest ABI supported by the C library.
Setting this option, for example, to 2.2 will provide ABI support
back to (e)glibc-2.2.
If this option is not set, (e)glibc will choose for you.
config LIBC_GLIBC_FORCE_UNWIND
bool
prompt "Force unwind support (READ HELP!)"
default n
help
If your toolchain fails building while building the C library
start files, or the complete C library, with a message like:
configure: error: forced unwind support is required
then you may try setting this to 'y'. Otherwise, leave it to 'n'.
The issue seems to be related to building NPTL on old versions
of glibc (and possibly eglibc as well) on some architectures
(seen on s390, s390x and x86_64).
config LIBC_GLIBC_USE_PORTS
bool
prompt "Use the ports addon"
default n
help
The ports addon contains some architecture ports that are not available
in the official distribution.
For example, this is the case for ARM with glibc-2.4 and above.
Say n only if you're sure that your architecture is in the official
distribution for your chosen version.
config LIBC_ADDONS_LIST
string
prompt "Extra addons"
default ""
help
Extra addons to include. Space separated list.
You need to specify neither linuxthreads nor nptl, as they are added
automagically for you depending on the threading model you choosed
earlier.
Eg.: crypt (for very old libces)
if LIBC_GLIBC_USE_PORTS || ( LIBC_ADDONS_LIST != "" )
comment "WARNING !!! "
comment "| For glibc >= 2.8, it can happen that the tarballs "
comment "| for the addons are not available for download. "
comment "| If that happens, bad luck... Try a previous version "
comment "| or try again later... :-( "
endif
if KERNEL_linux
choice LIBC_GLIBC_SUPPORTED_KERNEL
bool
prompt "Minimum supported kernel version"
default LIBC_GLIBC_KERNEL_VERSION_AS_HEADERS
config LIBC_GLIBC_KERNEL_VERSION_NONE
bool
prompt "Let ./configure decide"
help
Let ./configure decide what minimum kernel version glibc/eglibc
will be able to run against.
This will inclde legacy compatibility code for older kernels in
the C library, thus ensuring that it will run on a large number
of old kernels.
The minimum kernel version supported will be dependent upon the
target you build for. For example:
alpha*-*-linux-gnu Requires Linux 2.6.9 for NPTL
sh[34]-*-linux-gnu Requires Linux 2.6.11
powerpc* Requires Linux 2.4.19
arm*-*-linux-*gnueabi Requires Linux 2.6.16
config LIBC_GLIBC_KERNEL_VERSION_AS_HEADERS
bool
prompt "Same as kernel headers (default)"
help
Normaly, you'll want glibc/eglibc to run against the same kernel
version as the one used for the headers.
This is the default.
If enabled, crosstool-ng will use the chosen version of kernel
headers for the glibc minimum kernel version supported, which is
what gets passed to "--enable-kernel=" when configuring glibc.
Enabling this will ensure that no legacy compatibility code for
older kernels is built into your C libraries, but it will
be unable to run on kernel versions older than whichever kernel
headers version you've built the toolchain for.
If you know for sure that your toolchain will never need to build
applications that will run under a kernel version older than your
chosen kernel headers version (CT_KERNEL_VERSION), you can choose
"y" here.
config LIBC_GLIBC_KERNEL_VERSION_CHOSEN
bool
prompt "Specific kernel version"
help
Specify the earliest Linux kernel version you want glibc to
include support for. This does not have to match the kernel
headers version used for your toolchain. This controls what is
passed to the "--enable-kernel=" option to the glibc configure
script.
If you want to be able to statically link programs with your
toolchain's C library, make sure this kernel version is lower than
all kernels you wish to support to avoid "FATAL: kernel too old"
errors. The higher the version you specify, the less legacy code
will be built into libc.
Most people can leave this at the default value of "2.6.9".
if LIBC_GLIBC_KERNEL_VERSION_CHOSEN
config LIBC_GLIBC_MIN_KERNEL_VERSION
string
prompt "Minimum kernel version to support"
default "2.6.9"
help
Enter here the lowest kernel version glibc/eglibc will be able to
run against.
The minimum kernel version supported will be dependent upon the
target you build for. For example:
alpha*-*-linux-gnu Requires Linux 2.6.9 for NPTL
sh[34]-*-linux-gnu Requires Linux 2.6.11
powerpc* Requires Linux 2.4.19
arm*-*-linux-*gnueabi Requires Linux 2.6.16
Note that no sanity check is performed by crosstool-NG to ensure
that the value you enter here is appropriate for your target.
endif # LIBC_GLIBC_KERNEL_VERSION_CHOSEN
endchoice
config LIBC_GLIBC_MIN_KERNEL
string
default "" if LIBC_GLIBC_KERNEL_VERSION_NONE
default KERNEL_VERSION if LIBC_GLIBC_KERNEL_VERSION_AS_HEADERS
default LIBC_GLIBC_MIN_KERNEL_VERSION if LIBC_GLIBC_KERNEL_VERSION_CHOSEN
endif # KERNEL_linux