2013-06-30 21:29:00 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# gcc-initial
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
GCC_INITIAL_VERSION = $(GCC_VERSION)
|
.mk files: bulk aligment and whitespace cleanup of assignments
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.
This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.
Alignment of line continuation characters (\) is kept as-is.
The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'
Brief explanation of this command:
^\([A-Z0-9a-z_]\+\) a regular variable at the beginning of the line
\([?:+]\?=\) any assignment character =, :=, ?=, +=
\([^\\]\+\) any string not containing a line continuation
\([^\\ \t]\+\s*\\\) string, optional whitespace, followed by a
line continuation character
\(\s*\\\) optional whitespace, followed by a line
continuation character
Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.
This expression was tested on following test text: (initial tab not
included)
FOO = spaces before
FOO = spaces before and after
FOO = tab before
FOO = tab and spaces before
FOO = tab after
FOO = tab and spaces after
FOO = spaces and tab after
FOO = \
FOO = bar \
FOO = bar space \
FOO = \
GENIMAGE_DEPENDENCIES = host-pkgconf libconfuse
FOO += spaces before
FOO ?= spaces before and after
FOO :=
FOO =
FOO =
FOO =
FOO =
$(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
AT91BOOTSTRAP3_DEFCONFIG = \
AXEL_DISABLE_I18N=--i18n=0
After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
expression leaves the number of whitespace between the value and line
continuation character intact, but the whitespace before that could have
changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
actually makes the code more readable.
Finally, the end result was manually reviewed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-07 09:06:03 +02:00
|
|
|
GCC_INITIAL_SITE = $(GCC_SITE)
|
|
|
|
|
GCC_INITIAL_SOURCE = $(GCC_SOURCE)
|
2013-06-30 21:29:00 +02:00
|
|
|
|
2018-04-02 16:57:58 +02:00
|
|
|
# We do not have a 'gcc' package per-se; we only have two incarnations,
|
|
|
|
|
# gcc-initial and gcc-final. gcc-initial is just am internal step that
|
|
|
|
|
# users should not care about, while gcc-final is the one they shall see.
|
|
|
|
|
HOST_GCC_INITIAL_DL_SUBDIR = gcc
|
|
|
|
|
|
2013-06-30 21:29:00 +02:00
|
|
|
HOST_GCC_INITIAL_DEPENDENCIES = $(HOST_GCC_COMMON_DEPENDENCIES)
|
|
|
|
|
|
2015-11-04 08:32:39 +01:00
|
|
|
HOST_GCC_INITIAL_EXCLUDES = $(HOST_GCC_EXCLUDES)
|
2015-10-24 14:48:55 +02:00
|
|
|
HOST_GCC_INITIAL_POST_EXTRACT_HOOKS += HOST_GCC_FAKE_TESTSUITE
|
2013-06-30 21:29:04 +02:00
|
|
|
|
arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
- the core name
- the directory containing the overlay tarball
However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.
This has two main drawbacks:
- the overlay file must be named after the core,
- the tarball can not be compressed.
Furthermore, it also makes it extremely complex to implement a download
of that tarball.
So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.
Update the qemu-xtensa defconfig accordingly.
Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 14:21:56 +02:00
|
|
|
ifneq ($(ARCH_XTENSA_OVERLAY_FILE),)
|
2014-02-27 06:07:20 +01:00
|
|
|
HOST_GCC_INITIAL_POST_EXTRACT_HOOKS += HOST_GCC_XTENSA_OVERLAY_EXTRACT
|
2017-07-09 14:21:58 +02:00
|
|
|
HOST_GCC_INITIAL_EXTRA_DOWNLOADS += $(ARCH_XTENSA_OVERLAY_URL)
|
2013-06-30 21:29:00 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
HOST_GCC_INITIAL_POST_PATCH_HOOKS += HOST_GCC_APPLY_PATCHES
|
|
|
|
|
|
|
|
|
|
# gcc doesn't support in-tree build, so we create a 'build'
|
|
|
|
|
# subdirectory in the gcc sources, and build from there.
|
|
|
|
|
HOST_GCC_INITIAL_SUBDIR = build
|
|
|
|
|
|
|
|
|
|
HOST_GCC_INITIAL_PRE_CONFIGURE_HOOKS += HOST_GCC_CONFIGURE_SYMLINK
|
|
|
|
|
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_INITIAL_CONF_OPTS = \
|
|
|
|
|
$(HOST_GCC_COMMON_CONF_OPTS) \
|
2013-06-30 21:29:00 +02:00
|
|
|
--enable-languages=c \
|
|
|
|
|
--disable-shared \
|
|
|
|
|
--without-headers \
|
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
|
|
|
--disable-threads \
|
2013-06-30 21:29:00 +02:00
|
|
|
--with-newlib \
|
|
|
|
|
--disable-largefile \
|
gcc: use BR2_EXTRA_GCC_CONFIG_OPTIONS in gcc-initial and gcc-intermediate
When refactoring the internal toolchain backend logic, the code was
changed to pass the custom configure options given through
BR2_EXTRA_GCC_CONFIG_OPTIONS only for the gcc final pass, with the
idea that we're only interested by user customization for the final
compiler.
However, the beaglebone_defconfig was passing --with-float=hard
--with-fpu=vfpv3-d16 as BR2_EXTRA_GCC_CONFIG_OPTIONS, and since the
refactoring, it was causing build failures of the beaglebone_defconfig
(with messages saying that Busybox is built to use VFP arguments, but
libc/libm are not). This is due to the fact that the gcc intermediate,
which is used to build the C library, wasn't built to generate hard
float, while the final compiler was generating hard float.
So, we get back to the original situation where the options in
BR2_EXTRA_GCC_CONFIG_OPTIONS are passed to all of the compiler
passes. Of course, the specific case of hard float will be fixed by
following patches in this area, but the idea still remains: the three
gcc should have the same options, if those options affected the ABI of
the generated code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-14 00:27:24 +02:00
|
|
|
--disable-nls \
|
|
|
|
|
$(call qstrip,$(BR2_EXTRA_GCC_CONFIG_OPTIONS))
|
2013-06-30 21:29:00 +02:00
|
|
|
|
2013-09-04 16:18:14 +02:00
|
|
|
HOST_GCC_INITIAL_CONF_ENV = \
|
|
|
|
|
$(HOST_GCC_COMMON_CONF_ENV)
|
|
|
|
|
|
2015-10-17 15:09:09 +02:00
|
|
|
HOST_GCC_INITIAL_MAKE_OPTS = $(HOST_GCC_COMMON_MAKE_OPTS) all-gcc
|
2014-10-08 23:20:35 +02:00
|
|
|
HOST_GCC_INITIAL_INSTALL_OPTS = install-gcc
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
|
|
|
|
|
HOST_GCC_INITIAL_MAKE_OPTS += all-target-libgcc
|
|
|
|
|
HOST_GCC_INITIAL_INSTALL_OPTS += install-target-libgcc
|
|
|
|
|
endif
|
2013-06-30 21:29:00 +02:00
|
|
|
|
gcc: use toolchain wrapper
We have a toolchain wrapper for external toolchain, but it is also
beneficial for internal toolchains, for the following reasons:
1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the
compiler even if a package's build system doesn't honor CFLAGS.
2. It allows us to do the unsafe path check (i.e. -I/usr/include)
without patching gcc.
3. It makes it simpler to implement building each package with a
separate staging directory (per-package staging).
4. It makes it simpler to implement a compiler hash check for ccache.
The wrapper is reused from the external toolchain. A third CROSS_PATH_
option is added to the wrapper: in this case, the real executable is in
the same directory, with the extension .real.
The creation of the simple symlinks is merged with the creation of the
wrapper symlinks, otherwise part of the -gcc-ar handling logic would
have to be repeated.
The complex case-condition could be refactored with the one for the
external toolchain, but then it becomes even more complex because
they each have special corner cases. For example, the internal
toolchain has to handle *.real to avoid creating an extra indirection
after host-gcc-{final,initial}-rebuild.
Instead of creating the .real files, it would also have been possible
to install the internal toolchain in $(HOST_DIR)/opt, similar to what
we do for the external toolchain. However, then we would also have to
copy things to the sysroot and do more of the magic that the external
toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much
simpler.
Note that gcc-initial has to be wrapped as well, because it is used for
building libc and we want to apply the same magic when building libc.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
|
|
|
HOST_GCC_INITIAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS)
|
2016-09-28 10:00:56 +02:00
|
|
|
HOST_GCC_INITIAL_POST_BUILD_HOOKS += TOOLCHAIN_WRAPPER_BUILD
|
|
|
|
|
HOST_GCC_INITIAL_POST_INSTALL_HOOKS += TOOLCHAIN_WRAPPER_INSTALL
|
gcc: use toolchain wrapper
We have a toolchain wrapper for external toolchain, but it is also
beneficial for internal toolchains, for the following reasons:
1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the
compiler even if a package's build system doesn't honor CFLAGS.
2. It allows us to do the unsafe path check (i.e. -I/usr/include)
without patching gcc.
3. It makes it simpler to implement building each package with a
separate staging directory (per-package staging).
4. It makes it simpler to implement a compiler hash check for ccache.
The wrapper is reused from the external toolchain. A third CROSS_PATH_
option is added to the wrapper: in this case, the real executable is in
the same directory, with the extension .real.
The creation of the simple symlinks is merged with the creation of the
wrapper symlinks, otherwise part of the -gcc-ar handling logic would
have to be repeated.
The complex case-condition could be refactored with the one for the
external toolchain, but then it becomes even more complex because
they each have special corner cases. For example, the internal
toolchain has to handle *.real to avoid creating an extra indirection
after host-gcc-{final,initial}-rebuild.
Instead of creating the .real files, it would also have been possible
to install the internal toolchain in $(HOST_DIR)/opt, similar to what
we do for the external toolchain. However, then we would also have to
copy things to the sysroot and do more of the magic that the external
toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much
simpler.
Note that gcc-initial has to be wrapped as well, because it is used for
building libc and we want to apply the same magic when building libc.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
|
|
|
HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
|
|
|
|
|
|
2013-06-30 21:29:00 +02:00
|
|
|
$(eval $(host-autotools-package))
|
