summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Petazzoni <thomas.petazzoni@free-electrons.com>2016-08-30 21:33:28 (GMT)
committerThomas Petazzoni <thomas.petazzoni@free-electrons.com>2016-08-31 19:45:36 (GMT)
commit1bd02bc230e1b3b22ca3eb23fb3dcb91b878283a (patch)
tree0a45752e6878da0802542db13b85d4c880527f45
parent511a161b87424fbe06747b233242d1f3ff915bf2 (diff)
downloadbuildroot-refs/heads/next.tar.gz
buildroot-refs/heads/next.tar.bz2
gcc: remove BR2_GCC_ENABLE_TLS optionnext
The current BR2_GCC_ENABLE_TLS can cause users to make incorrect choices, and is not very useful. This options allows to decide whether we pass --enable-tls or --disable-tls to gcc, to enable or disable support for Thread Local Storage. Its behavior is: - The option is default to "y" but only exists if we're using uClibc/NPTL or glibc. - When we're using uClibc, the option can be disabled. So, in practice, this means that currently: - TLS support is always on for glibc - TLS support is on by default for uClibc/NPTL, but can be disabled in the configuration. This is in fact bad and causes the build failure reported in bug #7424 (this bug is still reproducible on master) - TLS support is always disabled for uClibc/no-thread and uClibc/linuxthreads. - TLS support is always disabled for musl. This does not cause any build failure, but musl can use TLS support, and therefore be more efficient. According to http://www.openwall.com/lists/musl/2012/10/04/1, "Note that if you've been building gcc with --disable-tls, __thread was already working but gets emulated (very poorly; it's slow and will abort() if it runs out of memory) through libgcc.". So, this commit completely removes the BR2_GCC_ENABLE_TLS and instead makes the right choice inside gcc.mk directly: - TLS support enabled for glibc, musl and uClibc/NPTL - TLS support in other cases, i.e uClibc/no-thread and uClibc/linuxthreads. We have intentionally *not* added the option to Config.in.legacy. Indeed, the new behavior is *exactly* the same as the older behavior, with the exception of: - People can no longer disable TLS support in uClibc/NPTL, which was anyway causing a build failure and therefore was not used. - TLS support is now enabled on musl, but people using musl already had BR2_GCC_ENABLE_TLS not set, so they wouldn't get the legacy warning. Fixes bug #7424. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
-rw-r--r--package/gcc/Config.in.host8
-rw-r--r--package/gcc/gcc.mk9
2 files changed, 6 insertions, 11 deletions
diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index 7262714..aa0a698 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -154,14 +154,6 @@ config BR2_TOOLCHAIN_BUILDROOT_FORTRAN
Fortran language and you want Fortran libraries to be
installed on your target system.
-config BR2_GCC_ENABLE_TLS
- bool "Enable compiler tls support" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC
- default y
- depends on BR2_PTHREADS_NATIVE || BR2_TOOLCHAIN_BUILDROOT_GLIBC
- help
- Enable the compiler to generate code for accessing
- thread local storage variables
-
config BR2_GCC_ENABLE_LTO
bool "Enable compiler link-time-optimization support"
select BR2_BINUTILS_ENABLE_LTO
diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index 39c3eeb..82050b4 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -133,10 +133,13 @@ ifeq ($(BR2_sparc)$(BR2_sparc64),y)
HOST_GCC_COMMON_CONF_OPTS += --disable-libsanitizer
endif
-ifeq ($(BR2_GCC_ENABLE_TLS),y)
-HOST_GCC_COMMON_CONF_OPTS += --enable-tls
-else
+# TLS support is not needed on uClibc/no-thread and
+# uClibc/linux-threads, otherwise, for all other situations (glibc,
+# musl and uClibc/NPTL), we need it.
+ifeq ($(BR2_TOOLCHAIN_BUILDROOT_UCLIBC)$(BR2_PTHREADS)$(BR2_PTHREADS_NONE),yy)
HOST_GCC_COMMON_CONF_OPTS += --disable-tls
+else
+HOST_GCC_COMMON_CONF_OPTS += --enable-tls
endif
ifeq ($(BR2_GCC_ENABLE_LTO),y)