Commit Graph

69 Commits

Author SHA1 Message Date
Bernd Kuhls
873d4019f7 package/gcc: disable libmpx for gcc6-based musl builds
Building this minimal defconfig

BR2_TOOLCHAIN_BUILDROOT_MUSL=y
BR2_GCC_VERSION_6_X=y

fails:

In file included from ../../../../libmpx/mpxrt/mpxrt.c:54:0:
../../../../libmpx/mpxrt/mpxrt.c: In function 'read_mpx_status_sig':
../../../../libmpx/mpxrt/mpxrt.h:52:42: error: invalid application of
'sizeof' to incomplete type 'struct _libc_fpstate'
 #define XSAVE_OFFSET_IN_FPMEM    sizeof (struct _libc_fpstate)

To fix disable libmpx for musl builds, other projects did the same:

3ec2211548
http://git.alpinelinux.org/cgit/aports/commit/main/gcc/APKBUILD?id=1830e485126ea9a95d763317fb0c508c1ff297d2

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-23 14:47:07 +02:00
Arnout Vandecappelle
3374941965 gcc: remove BR2_GCC_NEEDS_MPC
The blind option BR2_GCC_NEEDS_MPC was used to distinguish gcc versions
that rely on the mpc library and the ones that don't. But since a while
already, all the versions we support do need the mpc library. So this
symbol isn't needed anymore.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16 12:19:49 +02:00
Thomas Petazzoni
1bd02bc230 gcc: remove BR2_GCC_ENABLE_TLS option
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  (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 .

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2016-08-31 21:45:36 +02:00
Waldemar Brodkorb
5ab751ca44 toolchain-buildroot: allow to build ppc64(le) musl toolchains
Latest musl release supports ppc64 architecture (both big endian and
little endian), so this commit adds support for this.

Since musl implements the ELFv2 ABI for both big-endian and
little-endian PowerPC64, we have to force using this ABI on PowerPC64
big endian (normally elfv1 is the default).

Also, only gcc 6.x has the necessary changes to support musl on PowerPC
64, so we restrict the gcc version selection accordingly.

Tested with Qemu for big endian and little endian configurations.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add comment about the ABI flag in gcc.mk, rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-19 14:28:01 +02:00
Waldemar Brodkorb
c101f1b1b8 gcc: add hidden symbol for defaults
Some architectures, f.e. Blackfin doesn't support to configure GCC with
--with-cpu to set some CPU specific default CFLAGS (-mcpu=foo). Use a
hidden config symbol to give a hint which architecture supports it,
otherwise add defaults to toolchain wrapper for internal toolchains.

Idea from Thomas Petazzoni.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas:
 - simplify the Config.in logic with just one option named
   BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS, defined in package/gcc in one
   place.
 - improve the organization of the code and name of variables.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-04 10:58:40 +02:00
Yann E. MORIN
5c177415ee package/gcc: fix list of files of patch file to hash for ccache
When we build the list of patches to include to compute the hash for
ccache, a typo precented the special gcc-initial/ and gcc-final/
directories from a global patch dir to be included in the calculation.

Fix that by properly expanding the $(PKG) variable.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: He Chunhui <hchunhui@mail.ustc.edu.cn>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-07-04 10:46:44 +02:00
Samuel Martin
7de668a1de package/gcc: complete the logic on libquadmath
libquadmath requires wchar.

So, turn to positive logic and complete it to only enabling quadmath
support when it is available.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
He Chunhui
930467503a gcc: apply patches stored in global patches directories
When building host gcc, patches stored in global patches directories are
skipped. This patch fixes the unexpected behavior.

Signed-off-by: Chunhui He <hchunhui@mail.ustc.edu.cn>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas:
 - rename the loop variable from 'D' to 'patchdir'
 - add some additional comments
 - remove final ; at end of loop when applying the patches, since it's
   not needed]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 15:46:33 +02:00
Samuel Martin
6331b9c24a package/gcc: wrap gfortran
gfortran supports all options supported by gcc, so it can and should be called
via the toolchain wrapper.

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-01 22:55:05 +02:00
Samuel Martin
0a694c548d package/gcc: use BR2_USE_WCHAR to set gcc libquadmath option
BR2_TOOLCHAIN_BUILDROOT_WCHAR is only defined when uclibc is selected,
whereas BR2_USE_WCHAR is always defined. Due to this, we were disabling
quadmath support even with glibc or musl.

So, use BR2_USE_WCHAR to drive the gcc libquadmath option.

In addition, invert the logic of the condition to use positive logic,
and rework the comment to no longer mention gcc 4.6: libquadmath still
exists, and it still requires wchar support.

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-01 17:25:35 +02:00
Arnout Vandecappelle (Essensium/Mind)
b818f0d060 gcc: fix ccache hash of patches in BR2_GLOBAL_PATCH_DIR
In commit f4682cf933, a hash of the patches applied to gcc was created
to make sure that ccache can properly detect when the toolchain has
changed. The patches applied to gcc consist of the buildroot patches in
package/gcc, but also potentially patches in BR2_GLOBAL_PATCH_DIR.
However, the path to the patches in BR2_GLOBAL_PATCH_DIR was corrected
incorrectly, because it misses a /. So instead of:

$(BR2_GLOBAL_PATCH_DIR)/gcc-initial/*.patch

it would look for

$(BR2_GLOBAL_PATCH_DIR)gcc-initial/*.patch

In other words, if BR2_GLOBAL_PATCH_DIR doesn't end with /, the patches
in BR2_GLOBAL_PATCH_DIR are not taken into account in the ccache hash.

To fix, add the missing /

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: He Chunhui <hchunhui@mail.ustc.edu.cn>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-18 23:02:34 +02:00
Max Filippov
65eec9081e Revert "package/gcc: fix libgcc build for xtensa"
This reverts commit c44cf2cc97.
Now that xtensa gas don't move literals into .init and .fini this fix is
no longer needed.

See upstream commit
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4111950f363221c4641dc2f33bea61cc94f34906,
which was backported to all supported binutils version, under the name
*-xtensa-fix-.init-.fini-literals-moving.patch.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
[Thomas: add more details in the commit log, as suggested by Yann
E. Morin, and using information provided by Max.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20 22:10:34 +01:00
Thomas Petazzoni
c6e635735d gcc: drop gcc 4.5 specific code
We have removed gcc 4.5 support since a long time, so this commit
removes dead code that was only used when building a toolchain based
on gcc 4.5.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-09 10:38:01 +01:00
Gustavo Zacarias
a4a1c47f28 gcc: host-cloog is not needed for graphite support on gcc 5.x
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>
2015-12-07 08:34:17 +01:00
Thomas Petazzoni
4a8478b728 gcc: use <pkg>_EXCLUDES, not <pkg>_TAR_EXCLUDES
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>
2015-11-04 08:32:39 +01:00
Yann E. MORIN
e3b46be7f4 package/gcc: use generic extract commands
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-03 22:22:51 +01:00
Thomas Petazzoni
a7463a6c81 gcc: pass explicit gcc_cv_libc_provides_ssp also to gcc-final
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>
2015-10-18 15:35:49 +02:00
Arnout Vandecappelle
416326d47e gcc: use '.br_real' instead of '.real' suffix for the raw internal toolchain
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>
2015-10-17 10:50:20 +02:00
Waldemar Brodkorb
c4c7e9f4ef sparc64: fix toolchain building when C++ is enabled
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>
2015-10-12 23:45:01 +02:00
Arnout Vandecappelle
70a61bbfb3 gcc: sort the patches before they are hashed
$(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>
2015-10-04 20:21:15 +02:00
Max Filippov
3570732c64 xtensa: switch from text-section-literals to auto-litpools
Now that both binutils and gcc support auto-litpools use that option
instead of text-section-literals to be able to compile huge functions.

Fixes:
  http://autobuild.buildroot.net/results/dd384fe0ef02a4205bea66a4a16ca2062afe53b4/
  http://autobuild.buildroot.net/results/87dd357a4b883ea3cd75546b3d63c4c28245beee/
  http://autobuild.buildroot.net/results/b5bca00dec1ecb118c7fb9c10dee74c94809c831/
and many others.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-04 17:27:27 +01:00
Arnout Vandecappelle
fe3395258c gcc: remove the --with-pkgversion option from the ccache hash
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>
2015-10-04 18:22:21 +02:00
Arnout Vandecappelle
1e97b27873 ccache: support changing the output directory
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>
2015-10-04 18:22:21 +02:00
Arnout Vandecappelle
f4682cf933 ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain
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>
2015-10-04 18:22:21 +02:00
Arnout Vandecappelle
919c06c282 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 18:22:20 +02:00
Max Filippov
c44cf2cc97 package/gcc: fix libgcc build for xtensa
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>
2015-07-24 11:32:39 +02:00
Romain Naour
bc39b87e5a package/gcc: fix typo for CFLAGS_FOR_TARGET
CFLAGS_FOR_TARGET is initialized with GCC_COMMON_TARGET_CXXFLAGS.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-23 23:13:31 +02:00
Alexey Brodkin
0fe633cdff gcc: explicitly use C{XX}FLAGS_FOR_TARGET instead of --enable-target-optspace
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>
2015-07-22 23:20:50 +02:00
Thomas Petazzoni
22ed697d11 packages: do not use TAR_STRIP_COMPONENTS, but directly --strip-components
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-12 13:51:59 +02:00
Gustavo Zacarias
e0046e533f gcc: disable libsanitizer for sparc
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 .

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-16 07:59:40 +02:00
Gustavo Zacarias
314f0ef16c gcc: remove stray bfin --with-cpu exclusion
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>
2015-03-25 21:40:24 +01:00
Peter Kümmel
814f63ec32 toolchain: add link-time-optimization support
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>
2015-03-07 15:01:53 +01:00
Gustavo Zacarias
7f2a52ef83 gcc: make branding unconditional
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>
2015-03-03 21:58:43 +01:00
Yann E. MORIN
8f8e9162fa package/gcc: do not mourn avr32 for too long...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-14 17:44:52 +01:00
Samuel Martin
dd798a45c5 package/gcc: rename the conditional patch according to the new policy
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-02-03 14:51:43 +01:00
Gustavo Zacarias
9f86c71cd9 package/gcc: disable libitm for sparc <v9
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>
2015-01-15 09:36:16 +01:00
Thomas Petazzoni
c0b2c5985a gcc: do not use BR2_GCC_TARGET_TUNE anymore
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>
2014-11-07 00:14:30 +01:00
Jerzy Grzegorek
1769933d98 package: indentation cleanup
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-26 05:47:05 +01:00
Fabio Porcedda
1586ce3a3d apply-patches.sh: Use the "APPLY_PATCHES" variable to call the script
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>
2014-10-25 01:31:32 +02:00
Peter Korsgaard
d313a80d62 gcc: remove gcc snapshot option
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>
2014-10-12 12:09:34 +02:00
Thomas De Schampheleire
aaffd209fa packages: rename FOO_CONF_OPT into FOO_CONF_OPTS
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>
2014-10-04 18:54:16 +02:00
Thomas Petazzoni
45893484ac gcc/gcc-intermediate: remove package
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>
2014-09-14 23:20:59 +02:00
Jerzy Grzegorek
c7f4b96471 package: remove the trailing slash sign from <PKG>_SITE variable
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>
2014-07-31 23:17:46 +02:00
Steve Thomas
90aca35a4c gcc: add a BR2_GCC_ENABLE_GRAPHITE option
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>
2014-06-09 11:38:25 +02:00
Thomas Petazzoni
5f4d658d88 gcc: disable libsanitizer for musl
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>
2014-05-05 23:53:27 +02:00
Peter Korsgaard
42ebd7475d gcc: fixup "standard" gcc location after 'use default gcc 4.8.2 for microblaze'
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>
2014-04-30 00:27:51 +02:00
Waldemar Brodkorb
3f82e9dbcd use default gcc 4.8.2 for microblaze
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>
2014-04-28 22:14:27 +02:00
Gustavo Zacarias
554e29e267 package/gcc: disable libsanitizer for uClibc
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>
2014-04-24 13:46:43 +02:00
Peter Seiderer
0610a64cec gcc: fix snapshot compile
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>
2014-03-21 10:47:05 +01:00
Spenser Gilliland
9e0fbe41e2 gcc: add microblaze internal toolchain
Signed-off-by: Spenser Gilliland <spenser@gillilanding.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-12-06 22:45:42 +01:00