kumquat-buildroot/package/glibc/glibc.mk

128 lines
4.2 KiB
Makefile
Raw Normal View History

################################################################################
#
# glibc
#
################################################################################
ifeq ($(BR2_arc),y)
GLIBC_VERSION = arc-2018.03-release
GLIBC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,glibc,$(GLIBC_VERSION))
else
package/glibc: switch to using the maintenance branch glibc upstream has ruled against doing regular point-releases, but they do have a lot of interesting and important fixes for regressions and security. Backporting each patch, or cherry-picking individual patches is off limits for us, so we just switch to using the currently-latest HEAD of the maintenance branch instead. The version number is obtained with: $ git describe --match 'glibc-*' --abbrev=40 origin/release/2.26/master The alternative options were: - download the tarball from the git tree --> does not work; not an option - download the 2.26 tarball, and bundle the individual patches in Buildroot --> maintenance of patches is a burden; not an option - download the 2.26 tarball, maintain the list of patches to download from the git tree --> not an option for the same reason So we end up just doing a git clone. The git tree is today about ten times the size of the tarball, so a rough estimate makes it at about ten times the download time. Also upstream doesn't officially provide an https download location [1]. There is one but it's not reliable, sometimes the connection time out and end-up with a corrupted git repo: fatal: unable to access 'https://sourceware.org/git/glibc.git/': Failed to connect to sourceware.org port 443: Connection timed out So switch to using a git mirror from github which is updated once a day [2]. This allow at the same time to clone the git repository faster. Note: The glibc 2.26 patches are not kept for the arc toolchain since they are fixing an issue with the new float128 support introduced in x86, x86_64 and powerpc64le. [1] https://sourceware.org/git/?p=glibc.git;a=summary [2] https://github.com/bminor/glibc.git Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Evgeniy Didin <didin@synopsys.com> CC: Alexey Brodkin <abrodkin@synopsys.com> [Romain: bump 4b692dffb95ac4812b161eb6a16113d7e824982e] Signed-off-by: Romain Naour <romain.naour@gmail.com> [yann.morin.1998@free.fr: update comment to never decide on the mirror] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-10-29 10:52:48 +01:00
# Generate version string using:
# git describe --match 'glibc-*' --abbrev=40 origin/release/MAJOR.MINOR/master
GLIBC_VERSION = glibc-2.27-57-g6c99e37f6fb640a50a3113b2dbee5d5389843c1e
package/glibc: switch to using the maintenance branch glibc upstream has ruled against doing regular point-releases, but they do have a lot of interesting and important fixes for regressions and security. Backporting each patch, or cherry-picking individual patches is off limits for us, so we just switch to using the currently-latest HEAD of the maintenance branch instead. The version number is obtained with: $ git describe --match 'glibc-*' --abbrev=40 origin/release/2.26/master The alternative options were: - download the tarball from the git tree --> does not work; not an option - download the 2.26 tarball, and bundle the individual patches in Buildroot --> maintenance of patches is a burden; not an option - download the 2.26 tarball, maintain the list of patches to download from the git tree --> not an option for the same reason So we end up just doing a git clone. The git tree is today about ten times the size of the tarball, so a rough estimate makes it at about ten times the download time. Also upstream doesn't officially provide an https download location [1]. There is one but it's not reliable, sometimes the connection time out and end-up with a corrupted git repo: fatal: unable to access 'https://sourceware.org/git/glibc.git/': Failed to connect to sourceware.org port 443: Connection timed out So switch to using a git mirror from github which is updated once a day [2]. This allow at the same time to clone the git repository faster. Note: The glibc 2.26 patches are not kept for the arc toolchain since they are fixing an issue with the new float128 support introduced in x86, x86_64 and powerpc64le. [1] https://sourceware.org/git/?p=glibc.git;a=summary [2] https://github.com/bminor/glibc.git Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Evgeniy Didin <didin@synopsys.com> CC: Alexey Brodkin <abrodkin@synopsys.com> [Romain: bump 4b692dffb95ac4812b161eb6a16113d7e824982e] Signed-off-by: Romain Naour <romain.naour@gmail.com> [yann.morin.1998@free.fr: update comment to never decide on the mirror] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-10-29 10:52:48 +01:00
# Upstream doesn't officially provide an https download link.
# There is one (https://sourceware.org/git/glibc.git) but it's not reliable,
# sometimes the connection times out. So use an unofficial github mirror.
# When updating the version, check it on the official repository;
# *NEVER* decide on a version string by looking at the mirror.
# Then check that the mirror has been synced already (happens once a day.)
GLIBC_SITE = $(call github,bminor,glibc,$(GLIBC_VERSION))
endif
GLIBC_LICENSE = GPL-2.0+ (programs), LGPL-2.1+, BSD-3-Clause, MIT (library)
GLIBC_LICENSE_FILES = COPYING COPYING.LIB LICENSES
# glibc is part of the toolchain so disable the toolchain dependency
GLIBC_ADD_TOOLCHAIN_DEPENDENCY = NO
# Before glibc is configured, we must have the first stage
# cross-compiler and the kernel headers
GLIBC_DEPENDENCIES = host-gcc-initial linux-headers host-bison host-gawk
GLIBC_SUBDIR = build
GLIBC_INSTALL_STAGING = YES
GLIBC_INSTALL_STAGING_OPTS = install_root=$(STAGING_DIR) install
# Thumb build is broken, build in ARM mode
ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)
GLIBC_EXTRA_CFLAGS += -marm
endif
# MIPS64 defaults to n32 so pass the correct -mabi if
# we are using a different ABI. OABI32 is also used
# in MIPS so we pass -mabi=32 in this case as well
# even though it's not strictly necessary.
ifeq ($(BR2_MIPS_NABI64),y)
GLIBC_EXTRA_CFLAGS += -mabi=64
else ifeq ($(BR2_MIPS_OABI32),y)
GLIBC_EXTRA_CFLAGS += -mabi=32
endif
ifeq ($(BR2_ENABLE_DEBUG),y)
GLIBC_EXTRA_CFLAGS += -g
endif
# The stubs.h header is not installed by install-headers, but is
# needed for the gcc build. An empty stubs.h will work, as explained
# in http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html. The same trick
# is used by Crosstool-NG.
ifeq ($(BR2_TOOLCHAIN_BUILDROOT_GLIBC),y)
define GLIBC_ADD_MISSING_STUB_H
mkdir -p $(STAGING_DIR)/usr/include/gnu
touch $(STAGING_DIR)/usr/include/gnu/stubs.h
endef
endif
# Even though we use the autotools-package infrastructure, we have to
# override the default configure commands for several reasons:
#
# 1. We have to build out-of-tree, but we can't use the same
# 'symbolic link to configure' used with the gcc packages.
#
# 2. We have to execute the configure script with bash and not sh.
#
# Note that as mentionned in
# http://patches.openembedded.org/patch/38849/, glibc must be
# built with -O2, so we pass our own CFLAGS and CXXFLAGS below.
define GLIBC_CONFIGURE_CMDS
mkdir -p $(@D)/build
# Do the configuration
(cd $(@D)/build; \
$(TARGET_CONFIGURE_OPTS) \
CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \
CXXFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" \
$(SHELL) $(@D)/configure \
ac_cv_path_BASH_SHELL=/bin/bash \
libc_cv_forced_unwind=yes \
toolchain: switch to a two stage gcc build Currently, the internal toolchain backend does a three stage gcc build, with the following sequence of builds: - build gcc-initial - configure libc, install headers and start files - build gcc-intermediate - build libc - build gcc-final However, it turns out that this is not necessary, and only a two stage gcc build is needed. At some point, it was believed that a three stage gcc build was needed for NPTL based toolchains with old gcc versions, but even a gcc 4.4 build with a NPTL toolchain works fine. So, this commit switches the internal toolchain backend to use a two stage gcc build: just gcc-initial and gcc-final. It does so by: * Removing the custom dependency of all C libraries build step to host-gcc-intermediate. Now the C library packages simply have to depend on host-gcc-initial as a normal dependency (which they already do), and that's it. * Build and install both gcc *and* libgcc in host-gcc-initial. Previously, only gcc was built and installed in host-gcc-initial. libgcc was only done in host-gcc-intermediate, but now we need libgcc to build the C library. * Pass appropriate environment variables to get SSP (Stack Smashing Protection) to work properly: - Tell the compiler that the libc will provide the SSP support, by passing gcc_cv_libc_provides_ssp=yes. In Buildroot, we have chosen to use the SSP support from the C library instead of the SSP support from the compiler (this is not changed by this patch series, it was already the case). - Tell glibc to *not* build its own programs with SSP support. The issue is that if glibc detects that the compiler supports -fstack-protector, then glibc uses it to build a few things with SSP. However, at this point, the support is not complete (we only have host-gcc-initial, and the C library is not completely built). So, we pass libc_cv_ssp=no to tell the C library to not use SSP support itself. Note that this is not a big loss: only a few parts of the C library were built with -fstack-protector, not the entire library. * A special change is needed for ARC, because its libgcc depends on the C library, which breaks building libgcc in host-gcc-initial. This looks like a bug in the ARC compiler, as it does not obey the inhibit_libc variable which tells the compiler build process to *not* enable things that depend on the C library. So for now, in host-gcc-initial, we simply disable the build of libgmon.a for ARC. It's going to be built as part of host-gcc-final, so the final compiler will have gmon support. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-14 11:49:59 +02:00
libc_cv_ssp=no \
--target=$(GNU_TARGET_NAME) \
--host=$(GNU_TARGET_NAME) \
--build=$(GNU_HOST_NAME) \
--prefix=/usr \
--enable-shared \
$(if $(BR2_x86_64),--enable-lock-elision) \
--with-pkgversion="Buildroot" \
--without-cvs \
--disable-profile \
--without-gd \
--enable-obsolete-rpc \
--enable-kernel=$(call qstrip,$(BR2_TOOLCHAIN_HEADERS_AT_LEAST)) \
--with-headers=$(STAGING_DIR)/usr/include)
$(GLIBC_ADD_MISSING_STUB_H)
endef
#
# We also override the install to target commands since we only want
# to install the libraries, and nothing more.
#
GLIBC_LIBS_LIB = \
ld*.so.* libanl.so.* libc.so.* libcrypt.so.* libdl.so.* libgcc_s.so.* \
libm.so.* libpthread.so.* libresolv.so.* librt.so.* \
libutil.so.* libnss_files.so.* libnss_dns.so.* libmvec.so.*
ifeq ($(BR2_PACKAGE_GDB),y)
GLIBC_LIBS_LIB += libthread_db.so.*
endif
define GLIBC_INSTALL_TARGET_CMDS
for libpattern in $(GLIBC_LIBS_LIB); do \
$(call copy_toolchain_lib_root,$$libpattern) ; \
done
endef
$(eval $(autotools-package))