Disable libcilkrts when building static, as there is no static version:
https://software.intel.com/en-us/articles/intel-cilk-plus-runtime-library-libcilkrts-can-only-be-linked-dynamically/
Fixes the following toolchain build error when building for i386 and
BR2_STATIC_LIBS=y + BR2_TOOLCHAIN_BUILDROOT_CXX=y is set:
../../../libcilkrts/runtime/sysdep-unix.c:603:19:
fatal error: dlfcn.h: No such file or directory
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Adjust some patches to avoid patching the ChangeLog which isn't quite
the same.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng011.
This engenering build contains the following updates:
1. rebase binutils on top of the latest upstream master
2. update GCC to version 6.2
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng010.
This engenering build contains different fixes done to TLS and
PIE features. Appropriate custom patches are removed as they have
been added to eng010.
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add support for mips64, which is available since musl 1.1.15.
Only gcc 6.x has required support for it. Tested variations of
little/big endian and hard/soft float.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit
5ab751ca44 ("toolchain-buildroot: allow to
build ppc64(le) musl toolchains"), support for building a musl toolchain
for ppc64(le) was added. Since this support only works with gcc 6, some
additional dependencies have been added to the older gcc versions so
that they cannot be selected on ppc64(le)/musl.
Unfortunately, the expression of the dependency was wrong, and leads to
those older gcc versions being non-selectable if you're not using
musl. Indeed, the dependencies look like this:
depends on !BR2_powerpc64 && !BR2_powerpc64le && BR2_TOOLCHAIN_USES_MUSL
So as soon as you're not using musl, BR2_TOOLCHAIN_USES_MUSL is false,
so the entire condition is false, and the gcc version is not available.
Due to this, only gcc 6.x can be selected currently with uclibc or
glibc, which is clearly not the intended behavior.
This commit reworks those dependencies to:
depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_powerpc64 || BR2_powerpc64el))
which more clearly expresses what we want:
"We don't want to (have a toolchain that uses musl and (be building
either for PPC64 or PPC64le))"
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>
The three patches allow to compile applications using TLS emulation from
libgcc or C++ applications.
The patches 892-libgcc-mkmap-symver-support-skip_underscore.patch and
893-libgcc-config-bfin-use-the-generic-linker-version-in.patch fixes how
libgcc is generated, by making the necessary libgcc symbols declared
"GLOBAL", and therefore visible outside of libgcc. This fixes a large
number of undefined reference issues (for either C++ applications or
applications using TLS emulation). This was reported as gcc PR74748.
The patch 894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch
allows to build DWARF in FDPIC mode. This patch replaces the older
892-disable-dwarf-bfin.patch, as instead of disabling DWARF support, it
fixes it. This was reported as gcc PR68468.
In order to get C++ working without unresolved symbols, we also need to
disable symbol versioning (--disable-symvers). This is a remaining issue
in gcc which will be investigated at a later point.
Since this commit fixes C++ support in Blackfin, it re-enables the
selection of C++ support for this architecture.
Fixes:
(alsa-lib emutls)
http://autobuild.buildroot.net/results/8544ce58d75820666579db93a25ca5656a8efa8e/
(cairo emutls)
http://autobuild.buildroot.net/results/88b02a5dd5408318941ccbfcea0a9cbaa331500a/
(audiofile c++)
http://autobuild.buildroot.net/results/394e530c5dcd9ccb590eb151aeaadb37d11e0e39/
(assimp c++)
http://autobuild.buildroot.net/results/01f4be126c2d786a5ad7f220c2cf60539888a480/
(bellagio c++)
http://autobuild.buildroot.net/results/ada/ada44228bf13ec05382275bd6571396f5ba2b1f7/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng008.
Main updates were made for gcc. It was switched to GCC 6 and to
OSABI v4.
Besides this patch fixes buildroot ARC failures connected to
"crtbeginT.o" object file missing. This issue lead to two main errors:
1) "crtbeginT.o: No such file or directory", e. g. bootutils-1.0.0.
No comments are required here I hope.
2) Errors like "compiler cannot create executables", e.g.:
a) host-gcc-final-arc-2016.09-eng007 static build,
b) aespipe-2.4c.
That was caused because the test to determine if compiler is able to
create executables was failing due to missing "crtbeginT.o" file.
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As discussed with Waldemar, the C++ support for Blackfin is currently
broken, and we don't have a fix in sight for the 2016.08
release. Therefore, this commit disables C++ support entirely on the
Blackfin architecture in the internal toolchain backend.
This will avoid a significant number of Blackfin build failures, that
occur when building C++ packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Two patches are removed, as they have been upstreamed:
- 130-fix_build_with_gcc-6.patch (svn commit 233721, Git commit
8c3fa311caa86f61b4e28d1563d1110b44340fb2)
- 920-libgcc-remove-unistd-header.patch (svn commit 226092, Git commit
e940d7953f06af11d09229a29ecbcc1ba25b378d)
All other patches have simply been refreshed, with no manual edit
needed.
A build+runtime test has been done with an ARM, Cortex-A8, EABIhf, musl
configuration, booted under Qemu.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng007 tag plus a
couple of fixes on top of it that will all make its way in the
next engineering build.
We hope this patch will cure most buildroot ARC failures as it
contains important fixes:
1) PIE fix. We have added PIE support to ARC toolchain at last.
So that should prevent breakage of many packages. As ARC now
supports PIE we remove ARC from BR2_TOOLCHAIN_SUPPORTS_PIE
exclusion in toolchain/Config.in file.
2) Assembler fix. This patch also have changes that fixes frequent
assembler failures, e.g.:
http://autobuild.buildroot.net/results/543/5430b902d900943a34c1888e7e410bd5df367bc2//
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
[Thomas: remove uClibc PIE patch, since we have bumped uClibc in the
mean time, to a version that contains the PIE fix for ARC.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This engineering build fixes the kernel dwarf stack unwinder feature for
ARC targets.
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Related to:
4520524ba0
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With gcc 6.1.0 and binutils 2.26 internal bfin toolchain can be used. A
gcc patch is required, which was reported upstream.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
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>
This is only for the Buildroot toolchain backend.
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>
Fortran depends on libquadmath when available, make the buildroot
toolchain option depends on this new hidden symbol,
[Vincent: only do "HOST_GCC_FINAL_USR_LIBS += libquadmath" for i386 and
x86_64, otherwise it will fail saying "libquadmath.a: file not found"]
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>
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>
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>
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>
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>
With this commit we're starting a series of updates of ARC tools.
Significantly rewritten arc-2016.03 tools introduced way too many
problems highlighted by Buildroot autobuilder. Now in attempt to
resolve as many issues as possible by the time final release of
arc-2016.09 tools is cut we'll be executing arc-2016.09 series
with engineering snapshots like this one.
We decided to go this way instead of applying separate patches here
and there because ongoing development introduces quite a lot of
changes and separate patches are not practical in Buildroot.
Moreover this will give us very clean visibility of number of
issues we see (hopefully it will decrease over time).
One of the important changes introduced in this engineering build
is initial set of changes for proper support of PIE on ARC in terms
of both building on host and running on ARC target. I expect some
PIE-related build breakages to go away and new ones will be treated
as the high-priority issues to be fixed ASAP.
For now we only update Binutils and GCC while keeping GDB
as it is of arc-2016.03 release because there're some issues
we'd like to resolve before releasing it to wider audience.
So again note this is one of the first engineering builds of
arc-2016.09 series and it might have all kinds of breakages,
please don't use it for production builds.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-buildroot@synopsys.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following the removal of eglibc support, this commit replaces all
occurences of "(e)glibc" by just "glibc". Most of the occurences are in
package Config.in comments.
In addition, when the form "an (e)glibc ..." was used, it is replaced by
"a glibc ...".
[Peter: add new efi* packages, s/uclibc/uClibc as suggested by Romain,
systemd / liquid-dsp tweaks as suggested by Yann]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
130-fix_build_with_gcc-6.patch is upstream so remove it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Latest uClibc-ng 1.0.15 release fixed open issues with
microblaze shared library and linuxthreads support.
gcc 4.9.3 and gcc 5.3.0 require a small patch.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This change switches ARC tools to the most recent arc-2016.03
version.
ARC GNU tools of version arc-2016.03 bring some quite significant
changes like:
* Binutils v2.26+ (upstream commit id 202ac19 with additional ARC
* patches)
* GCC v4.8.5
* GDB 7.10
More about changes, improvements and fixes could be found here:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03
Note in this change we're adding sha512 checksums for
both binutils and gcc tarballs fetched from GitHub.
Build and run-tested in nSIM for both ARC700 and ARC HS38.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the host system compiler is gcc-6, this patch is needed to build
Buildroot toolchain and cleanly apply on gcc version 4.8.x to 5.x (not
needed for 4.7.x series).
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The eglibc support has been marked deprecated since 2015.08, so it's
time to remove it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Due to patch 840-microblaze-enable-dwarf-eh-support.patch, gcc 6.x
does not build:
../../gcc/config/microblaze/microblaze.c: In function 'void microblaze_expand_epilogue()':
../../gcc/config/microblaze/microblaze.c:3046: error: 'gen_rtx_raw_REG' was not declared in this scope
This patch was originally added to gcc 4.9 to make it capable of
building glibc. However, this is no longer needed with gcc 6.x, which
builds glibc just fine.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This change switches ARC tools to RC2 of the most recent arc-2016.03
version.
Essentially once final release is ready version will be bumped again.
ARC GNU tools of version arc-2016.03 bring some quite significant
changes like:
* Binutils v2.26+ (upstream commit id 202ac19 with additional ARC patches)
* GCC v4.8.5
* GDB 7.10
More about changes, improvements and fixes could be found here:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03-rc2
Also in this change we realign custom Buildroot patches for binutils and
gcc for ARC tools. Looks like earlier most of arch-independent patches
for binutils and gcc were either unintentionally removed or not even
added in patch folders for ARC's binutils and gcc. Now arch-independent
patches for binutils-2.26 and gcc-4.8.5 were added in
package/{binutils|gcc}/arc-2016.03-rc2 folders.
Build and run-tested in nSIM for both ARC700 and ARC HS38.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add support for m68k/coldfire. A gcc patch is required
to avoid gcc ICE.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds the support for gcc 6. This release allows to remove
a large number of our gcc patches, mainly thanks to the Xtensa and
musl related patches being merged upstream.
Patches kept with no changes:
100-uclibc-conf.patch
301-missing-execinfo_h.patch
810-arm-softfloat-libgcc.patch
830-arm_unbreak_armv4t.patch
840-microblaze-enable-dwarf-eh-support.patch
860-cilk-wchar.patch
890-fix-m68k-compile.patch
Patches dropped because they have been merged upstream, or were
already upstream backports:
120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged)
850-libstdcxx-uclibc-c99.patch (merged in a different form, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393)
870-xtensa-add-mauto-litpools-option.patch (upstream backport)
871-xtensa-reimplement-register-spilling.patch (upstream backport)
872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport)
873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport)
874-xtensa-add-uclinux-support.patch (upstream backport)
900-libitm-fixes-for-musl-support.patch (upstream backport)
901-fixincludes-update-for-musl-support.patch (upstream backport)
902-unwind-fix-for-musl.patch (upstream backport)
903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport)
904-musl-libc-config.patch (upstream backport)
905-add-musl-support-to-gcc.patch (upstream backport)
905-add-musl-support-to-gcc.patch (upstream backport)
906-mips-musl-support.patch (upstream backport)
907-x86-musl-support.patch (upstream backport)
908-arm-musl-support.patch (upstream backport)
909-aarch64-musl-support.patch (upstream backport)
Successfully build-time and run-time tested with
qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl
configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
After the commit f67a4f50e2 "gcc: preserve CXXFLAGS_FOR_TARGET"
target CFLAGS are passed to all libraries bundled with gcc. This breaks
libsanitizer on gcc-4.9.x when building with _FILE_OFFSET_BITS=64:
error: size of array ‘assertion_failed__837’ is negative
...
libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:837:1:
note: in expansion of macro ‘CHECK_SIZE_AND_OFFSET’
CHECK_SIZE_AND_OFFSET(dirent, d_ino);
This issue is fixed in the libsanitizer mainline and in gcc-5.x.
There's no issue with gcc-4.8.x and earlier.
Reported-by: Julien CORJON <corjon.j@ecagroup.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Backported from: https://llvm.org/svn/llvm-project/compiler-rt/trunk@220328
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
This allows to build a m68k toolchain with uClibc.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 2dcab526a9.
Now that gcc correctly propagates CXXFLAGS_FOR_TARGET for libstdc++
build this is no longer needed.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gcc-4.7.x, gcc-4.8.x and gcc-4.9.x don't propagate CXXFLAGS_FOR_TARGET to
CXXFLAGS for libstdc++ build. As a result libstdc++ is built without
TARGET_CFLAGS and may fail to link with applications using it, see e.g.
http://autobuild.buildroot.net/results/81a3bca5cbcf789c7ce1aa221a6a4154dd7c3917/
Instead of passing TARGET_ABI or TARGET_CFLAGS for libstdc++ in
--enable-cxx-flags parameter backport the patch that fixes propagation
of CXXFLAGS_FOR_TARGET to CXXFLAGS.
This issue is fixed in gcc-5.x
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit updates the gcc musl patches for gcc 4.7, 4.8 and 4.9 so
that the path to the dynamic linker encoded as "program interpreter"
in the generated binaries actually matches the symbolic link installed
by musl when building for mips soft-float.
Indeed, musl installs a symlink called ld-musl-mipsel-sf.so.1, but gcc
currently generates binaries that use /lib/ld-musl-mips.so as program
interpreter.
The fix is simply the one from
https://bitbucket.org/GregorR/musl-cross/commits/825219202365, i.e
adjust MUSL_DYNAMIC_LINKER in our musl gcc patches.
Thanks to these patches:
$ ./host/usr/bin/mipsel-linux-readelf -a ./target/bin/busybox
[...]
[Requesting program interpreter: /lib/ld-musl-mipsel-sf.so.1]
[...]
gcc 5.x doesn't need any fix because the musl patches already use the
right value.
Fixes bug #7562.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
It's been deprecated for some time now.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
[Thomas: move option to Config.in.legacy, as noticed by Peter.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We're already using 4.9.x as default, and have 4.8.x on the lower side
together with 5.x (5.3.0) on the higher side.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add the Cortex A17 variant. This core is considered a replacement
of the Cortex A12 and is supported by gcc 5 / binutils 2.25+
Suggested-by: Ross Green <greenfross@netscape.net>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This change introduces newer ARC toolchain in Buildroot.
That new arc-2015.12 release doesn't bring any significant changes
but mostly is focused on fixes and minor improvements here and there.
Most noticeable changes are:
* GCC: Source update to v4.8.5
* GDB: Updated to upstream 7.10 release.
You may find more info on fixes and improvements in that release at:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.12
Signed-off-by: Lada Trimasova <ltrimas@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
These patches solve several problems that were discovered
after bumping tools to arc-2015.12-rc1.
The fixes were done in development tree arc-4.8-dev and will be
a part of the next release of ARC GNU tools.
Once that new release happens these patches must be removed.
Signed-off-by: Lada Trimasova <ltrimas@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This change introduces newer ARC toolchain in Buildroot.
Note this is the first release candidate and we'll probably see another
RC before cutting the final release.
That new arc-2015.12 release doesn't bring any significant changes but
mostly is focused on fixes and minor improvements here and there.
Most noticeable changes are:
* GCC updated to v4.8.5
* GDB updated to 7.10
You may find more info on fixes and improvements in that release at:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.12-rc1
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
201-libgcc-remove-unistd-header.patch is upstream so remove it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
This patch fixes compiler error during libbroadvoice build.
The comparison arguments where not correctly handled.
The fix is done in development tree:
b4035128ba
and will be a part of the next release of ARC GNU tools.
Once that new release happens this patch must be removed.
Fixes:
http://autobuild.buildroot.net/results/bea/beace68a19382b43370c798dcf7d2ef412f9d75e/
Signed-off-by: Lada Trimasova <ltrimas@synopsys.com>
Cc: 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>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The explanations given in the commit log of 7d6c79 (Compile static
versions of gcc libraries) do not explain why we have to provide custom
configure commands, instead of just adding --enable-static to the
configure options.
Add a comment in the code that explains why that is so. Add a pointer to
the ML archives with the explanations, too.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jérôme Pouiller <jezz@sysmic.org>
Acked-by: Jérôme Pouiller <jezz@sysmic.org>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building with -mtune=e6500 led to build failures in glibc (probably in
uclibc as well) because gcc was built for a 32-bit target even though
the target tuple is powerpc64-*. This lead to a mix of 32-bit and
64-bit support and build errors like:
fatal error: gnu/lib-names-32.h: No such file or directory
The root cause is that the configure script is not handling e6500
correctly, because of stupid typo in the condition.
Change has been submitted upstream.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Alvaro Gamez <alvaro.gamez@hazent.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Doing a symlink results in incorrect behavior:
$ x86_64-buildroot-linux-gnux32-cc
--version
ccache: error: execv of [...]/x86_64-buildroot-linux-gnux32-cc.br_real.br_real failed: No such file or directory
$ x86_64-buildroot-linux-gnux32-gcc --version
x86_64-buildroot-linux-gnux32-gcc.br_real (Buildroot 2015.11-git-00965-g8d89653-dirty) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Note the double .br_real on the invocation by toolchain-wrapper.
[Thomas: use 'ln -f' instead of 'cp -l', as suggested by Arnout.]
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
Now that we are always explicitly passing gcc_cv_libc_provides_ssp,
there is no longer any reason to modify the gcc configure/configure.ac
to take into account the musl case. When a musl toolchain is being
built, BR2_TOOLCHAIN_HAS_SSP is always 'y', and therefore
gcc_cv_libc_provides_ssp=yes is always passed when building
gcc-initial and gcc-final.
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>
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>
- Add support for mips32r6 and mips64r6 target architecture variants
- Disable unsupported gcc versions
- Disable unsupported binutils versions
- Disable unsupported external toolchains
- Disable unsuported C libraries
- Add a hook in order to make glibc compile for MIPS R6.
[Thomas: slightly tweak the glibc hack explanation, to make it
hopefully clearer.]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
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>
With support from assembler this option allows compiling huge functions,
where single literal pool at the beginning of a function may not be
reachable by L32R instructions at its end.
Currently assembler --auto-litpools option cannot deal with literals
used from multiple locations separated by more than 256 KBytes of code.
Don't turn constants into literals, instead use MOVI instruction to load
them into registers and let the assembler turn them into literals as
necessary.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
Now that the calls to gcc always pass through the toolchain wrapper, it
is no longer necessary to patch gcc to support poisoning.
This does have the disadvantage that there is no unsafe path check for
libc, libgcc and libstdc++ (all of these are built before the wrapper
exists). But we can assume that the toolchain components themselves
should be pretty safe.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: 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>
gcc used to be installed into $(HOST_DIR)/usr/$(GNU_TARGET_NAME) but
since gcc 4.9 this is no longer the case. Therefore, the cc -> gcc
symlink that is created in that we create in that directory is dead.
There don't seem to have been any problems due to the missing gcc and
cc in $(HOST_DIR)/usr/$(GNU_TARGET_NAME), things seems to build fine
without it. The cc -> gcc symlinks in general should not be needed
anyway, since we always pass the appropriate CC variable to the
package build system.
Therefore, let's remove the cc -> gcc symlink in
$(HOST_DIR)/usr/$(GNU_TARGET_NAME) - also for pre-4.9 gcc versions.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When gcc 4.9.x was bumped from 4.9.2 to 4.9.3 in commit
2fed00ea1e, patch
920-libgcc-remove-unistd-header.patch was removed with the argument
that it had been applied upstream.
However, it is not the case, and the patch continues to apply fine on
gcc 4.9.3, and is actually needed to make gcc build properly on
NIOS-II.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit wires up the gcc version dependency mechanism in the
internal toolchain backend by making the gcc version choice in the gcc
package Config.in.host select the appropriate
BR2_TOOLCHAIN_GCC_AT_LEAST_* option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Rename the binutils configuration option to match that one used by gcc
where the patchlevel is explicitly left out.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
Also rename the BR2_GCC_VERSION_5_1_X symbol to BR2_GCC_VERSION_5_X to
reflect this change to match the new versioning scheme.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
I'm happy to update GNU tools for ARC cores to the most recent
arc-2015.06 release.
This release brings following major improvements:
* GCC: source update to v4.8.4
* GCC: C ABI compatibility between MetaWare and GNU toolchains
* uClibc: support for thread local storage and Native Pthread Library (NPTL)
* GDB: updated to version 7.9.1
Also a lot of fixes and improvements has been done, please refer to
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.06
for more details.
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: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This combination causes a compilation failure of the host-gcc-final
recipe like this one:
/br/output/host/usr/mips-buildroot-linux-gnu/bin/ld:
.libs/gload.o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not
be used when making a shared object; recompile with -fPIC
The problem is the file 'libatomic/gload.c' is compiled without -fPIC
when using binutils-2.25. All gcc (with libatomic) versions below 4.9.3
are affected by this issue.
Here is a summary of affected/unaffected versions in Buildroot:
4.7.x: unaffected (doesn't have libatomic)
4.8.x: affected
4.9.x: unaffected (we have 4.9.3 which is fixed)
5.1.x: unaffected
The fix can be found here:
57f5c0954f
However, given the following reasons...
- Upstream gcc 4.8 branch is closed.
- The fix is very hard to backport from 4.9 to 4.8.
- This stuff is insanely sensitive and not working at all could be
better than looking like it works but not quite.
...I think the best choice is to disable that combination in Buildroot.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When working with GCC initial at override source dir mode the
HOST_GCC_INITIAL_POST_PATCH_HOOKS is not called and compilation failes.
The solution is to use HOST_GCC_INITIAL_POST_RSYNC_HOOKS since this hook
is being called at override source dir mode.
Signed-off-by: Tal Zilcer <talz@ezchip.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In buildroot we maintain a couple off-the-tree patches.
In particular for binutils and gcc packages.
Because we have many versions of mentioned packages patches for each
particular version reside in a folder which name matches full version
name of the package.
For example we used to have patches for binutils distributed as part of
arc-2014.12 tools in folder ""package/binutils/arc-2014.12". Now with
bump of ARC tools version we need to rename folder with patches to
"arc-2015.06-rc1".
The same applies to gcc.
Should fix http://autobuild.buildroot.net/results/2b2/2b27a4a64c0b225ae479ecfccf7a97f5ea95598c/
As discussed before it's not possible to reproduce reported problem on recent
Fedora 21/22 distros (at least we know about them) but I may confirm that
patches were applied fine and everything was built well. Hopefully reported
build failure goes away now.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
