See https://gcc.gnu.org/gcc-5/changes.html
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As reported by Steven Noonan, the variable recently introduced in the
package infrastructure to exclude certain parts of an archive from
being extracted is <pkg>_EXCLUDES, not <pkg>_TAR_EXCLUDES. However,
the gcc code was incorrectly using <pkg>_TAR_EXCLUDES. This commit
fixes that.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Steven Noonan <steven@uplinklabs.net>
During the gcc-initial build, we already pass
gcc_cv_libc_provides_ssp=yes explicitly when SSP support will be
available in the C library: at this point in time the C library is not
yet built, so gcc cannot detect if it will support SSP or not.
However, it turns out that there are some situations for which it is
also useful to tell gcc explicitly whether the SSP support is
available or not: the gcc logic to decide whether uClibc has SSP
support or not is broken since uClibc-ng bumped the glibc version it
pretends to be.
So, this commit makes sure that we explicitly pass
gcc_cv_libc_provides_ssp both to gcc-initial and gcc-final, and that
we're always passing either 'yes' or 'no'.
Fixes:
http://autobuild.buildroot.org/results/778/778e6309ba834cc70f8243a4f6c664c0bcaeb7c5/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
If an externally built (non-Buildroot) toolchain also wraps the toolchain
executables, there is a risk that it will also use the '.real' extension.
To minimise this risk, use a more buildroot-specific extension instead:
'.br_real', so we can detect that the external toolchain is built using
Buildroot and get to the raw toolchain binaries.
[Peter: reword description]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Disable libsanitizer for sparc64, too. Same problem as for
sparc, see https://bugs.busybox.net/show_bug.cgi?id=7951
Reported-By: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
$(wildcard ...) in make doesn't sort the files, so the order of the
hashed files is not predictable. Therefore, the ccache hash could
change from one build to another. We don't want that, so sort the
files explicitly.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
One of the gcc configure options that we hash for ccache is
--with-pkgversion which is set to something like Buildroot
2015.11-git-00426-ge7e7e4f - i.e., it will change with every buildroot
commit. That's obviously not wanted, so substitute this away.
Also add a \n to the printf so the output is a bit more readable.
[Peter: update documentation to match]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When building in a different output directory than the original build,
there will currently be a lot of ccache misses because in many cases
there is some -I/... absolute path in the compilation. Ccache has an
option CCACHE_BASEDIR to substitute absolute paths with relative paths,
so they wil be the same in the hash (and in the output).
Since there are some disadvantages to this path rewriting, it is made
optional as BR2_CCACHE_USE_BASEDIR. It defaults to y because the
usefulness of ccache is severely reduced without this option.
In addition to CCACHE_BASEDIR, we also substitute away the occurences
of $(HOST_DIR) in the calculation of the compiler hash. This is done
regardless of the setting of BR2_CCACHE_USE_BASEDIR because it's
quite harmless.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current ccache disables hashing of the compiler executable itself,
because using the default 'mtime' doesn't work in buildroot: we always
rebuild the compiler, so the mtime is always different, so the cache
always misses.
However, in the current situation, if a user changes the compiler
configuration (which would result in the compiler generating different
object files than before) and does 'make clean all', ccache may in fact
reuse object files from the previous run. This rarely gives problems,
because
(1) the cache expires quite quickly (it's only 1GB by default),
(2) radically changing compiler options will cause cache misses because
different header files are used,
(3) many compiler changes (e.g. changing -mtune) have little practical
effect because the resulting code is usually still compatible,
(4) we currently don't use CCACHE_BASEDIR, and almost all object files
will contain an absolute path (e.g. in debug info), so when
building in a different directory, most of it will miss,
(5) we do mostly build test, and many of the potential problems only
appear at runtime.
Still, when ccache _does_ use the wrong cached object files, the
effects are really weird and hard to debug. Also, we want reproducible
builds and obviously the above makes builds non-reproducible. So we
have a FAQ entry that warns against using ccache and tells the user to
clear the cache in case of problems.
Now that ccache is called from the toolchain wrapper, it is in fact
possible to at least use the 'mtime' compiler hash for the external
toolchain and for the host-gcc. Indeed, in this case, the compiler
executable comes from a tarball so the mtime will be a good reference
for its state. Therefore, the patch (sed script) that changes the
default from 'mtime' to 'none' is removed.
For the internal toolchain, we can do better by providing a hash of
the relevant toolchain options. We are only interested in things that
affect the compiler itself, because ccache also processes the header
files and it doesn't look at libraries because it doesn't cache the
link step, just compilation. Everything that affects the compiler
itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of
course, also the compiler source itself is relevant, so the source
tarball and all the patches are included in the hash. For this purpose,
a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced.
The following procedure tests the ccache behaviour:
Use this defconfig:
BR2_arm=y
BR2_CCACHE=y
make
readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os
-> Tag_CPU_name: "ARM926EJ-S"
Now make menuconfig, change variant into BR2_cortex_a9
make clean; make
readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os
-> Tag_CPU_name: "ARM926EJ-S"
should be "Cortex-A9"
After this commit, it is "Cortex-A9".
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Danomi Manchego <danomimanchego123@gmail.com>
Cc: Károly Kasza <kaszak@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
xtensa libgcc can't be built with -mtext-section-literals flag, now
coming from TARGET_CFLAGS, because it needs to emit literals to
.init/.fini sections, which is not currently supported.
Filter -mtext-section-literals flag out of GCC_COMMON_TARGET_CFLAGS.
Suggested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The gcc.mk file is passing --enable-target-optspace to gcc configure
script, to ask for space-optimized (-Os) target libraries. However,
passing this option has the effect of overriding any custom
CFLAGS_FOR_TARGET or CXXFLAGS_FOR_TARGET values that may be passed.
These are some situations when it is required to pass custom flags on
buildong
of libgcc:
* Default flags "-g -Os" lead to build isses as with PowerPC on gcc 4.5
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810)
* Particular CPU requires specific instructions for HW support
* Deep optimizations
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Normally libsanitizer handles the different functionalities gracefully for
each architecture, but it doesn't seem to be the case for SPARC.
Since in general it doesn't support anything for SPARC just disable it.
Fixes bug #7951.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support an internal bfin toolchain hence it's dead code.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add a new option BR2_GCC_ENABLE_LTO that builds gcc and binutils with
LTO support.
Individual packages still have to enable LTO explicitly by passing '-flto' to
GCC, which passes it on to the linker. This option does not add that flag
globally. Some packages detect if the compiler supports LTO and enable the flag
if it does.
To support LTO, ar and ranlib must be called with an argument which triggers the
usage of the LTO plugin. Since GCC doesn't call these tools itself, it instead
provides wrappers for ar and ranlib that pass the LTO arguments. This way
existing Makefiles don't need to be changed for LTO support. However, these
wrappers are called <tuple>-gcc-ar which matches the pattern to link to the
buildroot wrapper in the external toolchain logic. So the external toolchain
logic is updated to provide the correct symlink.
[Thomas:
- Add a separate BR2_BINUTILS_ENABLE_LTO option to enable LTO
support in binutils. This is a blind option, selected by
BR2_GCC_ENABLE_LTO. It just avoids having binutils.mk poke
directly into gcc Config.in options.
- Remove the check on the AVR32 special gcc version, which we don't
support anymore.
- Adapt the help text of the LTO Config.in option to no longer
mention "Since version 4.5", since we only support gcc >= 4.5 in
Buildroot anyway.
- Fix typo in toolchain-external.mk comment.]
Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We don't support older versions that can't handle it any more.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libitm (transactional memory) needs SPARC V9+ ISA, otherwise when
enabling C++ the toolchain fails to build:
/tmp/cclQ6hrD.s: Assembler messages:
/tmp/cclQ6hrD.s:1261: Error: Architecture mismatch on "rd".
/tmp/cclQ6hrD.s:1261: (Requires v9|v9a|v9b; requested architecture is
v8.)
Makefile:517: recipe for target 'beginend.lo' failed
make[5]: *** [beginend.lo] Error 1
So disable it for our current (v8, leon3) support.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the BR2_GCC_TARGET_TUNE value is always empty now, there is no
longer a point in using it in the gcc package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To easy up adding optional parameters when calling the
"apply-patches.sh" add and use the "APPLY_PATCHES" variable to execute
the script.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As discussed during the dev days. It is broken for uClibc/musl and
architectures not using mainline gcc, so it has only very limited
usefulness.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_CONF_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we have switched to a two steps gcc build process that uses
only gcc-initial and gcc-final, we can get rid of the gcc-intermediate
package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the trailing slash is stripped from $($(PKG)_SITE) by pkg-generic.mk:
$(call DOWNLOAD,$($(PKG)_SITE:/=)/$($(PKG)_SOURCE))
so it is redundant.
This patch removes it from $(PKG)_SITE variable for BR consistency.
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The gcc graphite optimisations such as loop-interchange, blocking
and loop-flattening, also known as graphite are an optional feature of
gcc that is very well supported since about gcc version 4.5.
This patch adds support for graphite for the toolchain as an optional
flag for versions 4.8 onwards as an optional flag, that is disabled by
default.
Signed-off-by: Steve Thomas <scjthm@live.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A build issue affects libsanitizer on musl toolchains, even with
previous versions of gcc such as 4.8.x, so we disable building
libsanitizer when working with musl.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Somehow the 'else' part got dropped from commit 3f82e9dbcd (use default gcc
4.8.2 for microblaze), breaking download for "normal" architectures.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Upstream gcc 4.8.2 works fine for microblaze, no need for
Xilinx Git.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libsanitizer requires wordexp() support which we lack in our current
default uClibc configurations (and it's fat & big).
Hence disable it when the toolchain is uClibc-based.
It only affects gcc 4.9+ since it's default on now for supported
platforms.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add gcc snapshot versions dependency on host-flex and host-bison
(done as suggested by Thomas Petazzoni [1]).
Fixes gcc snapshot version 4.9-20140309 compile failure [2].
Tested the following buildroot configs
BR2_arm=y
BR2_cortex_a9=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_BINUTILS_VERSION_2_24=y
BR2_GCC_VERSION_SNAP=y
BR2_GCC_SNAP_DATE="4.9-20140309"
and
BR2_arcle=y
For the ARC case disabled the BINUTILS_FROM_GIT host-flex and host-bison
dependency.
[1] http://lists.busybox.net/pipermail/buildroot/2014-March/092490.html
[2] http://lists.busybox.net/pipermail/buildroot/2014-March/092459.html
[Peter: simplify logic]
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The github release mechanism only supports .tar.gz, hence the ugly
GCC_UNPACK variable.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While the generic package handler checks for a directory with patches
before starting apply-patches.sh, this is not the case for gcc: the
script is called, even if there is no directory with patches. This results
into a build failure, as apply-patches exits with error code 1 if the
directory doesn't exist.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The mudflap library is only useful if one uses the -fmudflap gcc
option to do more checks on pointers/arrays. This commit adds an
option to enable/disable mudflap support at the gcc level. By default,
it is disabled, which saves a little bit of build time compared to the
default of gcc which consists in enabling mudflap support.
Since mudflap is now disabled by default, and ensured to never be enabled
on platforms where it is not available, some gcc.mk code that was used to
disable mudflap in problematic configurations can be removed.
Whether -fmudflap is used when building is left to the user.
[Peter: tweak commit text, fix white space]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The HOST_GCC_CONFIGURE_SYMLINK creates a symbolic link
$(@D)/build/configure -> $(@D)/configure for each build step of
gcc. However, it was only using 'ln -s' and not 'ln -sf', which was
causing problems when doing 'make host-gcc-final-reconfigure' for
example, because the configure commands (including this macro) are
being re-executed, but the symbolic link already exists.
Changing this symbolic link creation to 'ln -sf' fixes this problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add host-elf2flt to the gcc common dependencies so we get it built after
binutils but before gcc/uclibc since it's required for all packages and
in some uClibc configuration scenarios.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Make 3.82 no longer sort the result of wildcards (see
http://comments.gmane.org/gmane.comp.gnu.make.bugs/4260). This may break
build reproducibility.
This patch sort results of wildcards to ensure reproducibility.
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Fixes a build issue with the avr32 toolchain:
http://jenkins.free-electrons.com/job/buildroot/config=atngw100_defconfig/104/
Invalid configuration `MAKEINFO=missing': machine `MAKEINFO=missing' not
recognized
Instead pass it in the environment of ./configure, similar to how it was
done originally in 62322acb2c (toolchain/gcc: disable makeinfo).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The documentation of older GCC versions (E.G. 4.3.x) contain constructs
that are no longer accepted by recent (5.x) versions of makeinfo, breaking
the build.
The documentation isn't really needed, and takes up extra space/build time,
so work around it by disabling documentation, like we had before the
conversion of the toolchain to the package infrastructure.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
libmudflap doesn't build for a thumb(1) toolchain so disable it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This fixes multiple issues, including:
- 'operand out of range' errors (due to defaulting to
medium calls instead of short calls)
- library dependencies that were not being found
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Until now, we were using the default ARM instruction set, as used by
the toolchain: the 32 bits ARM instruction set for the internal
backend, and for external toolchain, whatever default was chosen when
the toolchain was generated.
This commit adds support for the Thumb2 instruction set. To do so, it:
* provides a menuconfig choice between ARM and Thumb2. The choice is
only shown when Thumb2 is supported, i.e on ARMv7-A CPUs.
* passes the --with-mode={arm,thumb} option when building gcc in the
internal backend. This tells the compiler which type of
instructions it should generate.
* passes the m{arm,thumb} option in the external toolchain
wrapper. ARM and Thumb2 code can freely be mixed together, so the
fact that the C library has been built either ARM or Thumb2 and
that the rest of the code is built Thumb2 or ARM is not a problem.
[Peter: fix empty BR2_GCC_TARGET_MODE check]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
