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>
Even though this is only RC1 it's been heavily used internally so it should
not be any worse than existing arc-2014.12.
Moreover this relase (and so its RC1) finally delivers support of NPTL
for ARC in uClibc.
That's why it would be good to allow interested users to start trying it
(for example WebKit and apps that use WebKit could be successfully built
and run) also it will be helpful to run that new toolchain through
autobuilder in attempt to find any hidden regressions so we have a solid
toolchain for release.
If there's an interest in that patch more patches will follow with
subsequent RCs and essentially on appearence or relese Buildroot will be
updated with it.
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>
Drop 110-pr64896.patch and 920-libgcc-remove-unistd-header.patch since
they're upstream.
Tweak 850-libstdcxx-uclibc-c99.patch for this new release.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we have added gcc 5.1, it's time to make gcc 4.9 the default
version used in Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds support for gcc 5.1 in Buildroot. In terms of gcc
patches, compared to gcc 4.9.x:
* Kept as is, sometimes after minor adjusments:
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
850-libstdcxx-uclibc-c99.patch
860-cilk-wchar.patch
* Dropped:
110-pr64896.patch
111-pr65730.patch
* Split in multiple parts:
900-musl-support.patch
The patches from Crosstool-NG for muls support are used instead of
one single patch.
* Renamed:
910-gcc-poison-system-directories.patch to
200-gcc-poison-system-directories.patch
920-libgcc-remove-unistd-header.patch to
201-libgcc-remove-unistd-header.patch
Since the 9xx part of the series is now used by the various musl
related patches.
We have tested the following configurations, with a minimal Busybox
system:
* ARM, uClibc-ng
* ARM, glibc
* ARM, musl
* x86, uClibc-ng and uClibc 0.9.33.2
* x86, glibc
* x86, musl
All of the configurations built fine. All the configurations boot fine
in Qemu, except x86/uClibc (either ng or 0.9.33.2), it segfaults when
running init:
devtmpfs: mounted
Freeing unused kernel memory: 300K (c1389000 - c13d4000)
init[1]: segfault at 0 ip b77708c1 sp bfa9bb0c error 4 in ld-uClibc-0.9.33.2.so[b776c000+6000]
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
We'll give some time for the uClibc developers to fix the problem
before taking other measures in Buildroot to exclude gcc 5.1 from a
x86/uClibc configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Otherwise it's a no-op for sh4.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--disable-install-libiberty configure option is broken
in gcc 4.8.x, so libiberty.a is always installed in HOST_DIR.
This library broke the host-gdb build due to a fpic/fPIC issue.
Note: host-binutils-arc-2014.12 install libiberty.a in HOST_DIR
but it was overwritten by the gcc one. The host-binutils's
libiberty.a also broke the host-gdb build. This should be
fixed in a followup patch.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
--disable-install-libiberty configure option is broken
in gcc 4.8.x, so libiberty.a is always installed in HOST_DIR.
This library broke the host-gdb build due to a fpic/fPIC issue.
Fixes:
http://autobuild.buildroot.net/results/28f/28f3074e99a35f4321dad2fa6c5abdad14d2d2c6/
And many more.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
It's required in some 32-bit architectures for the extended (64-bit)
atomic operations, like __sync_add_and_fetch_8.
These arches are at least: i386, mips & mipsel.
Target size growth is ~15 KiB for ARM.
Signed-off-by: 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>
Now that largefile is mandatory remove support for non-lfs
tweaks/variables in the package infra and the gcc build.
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>
It was kept for the internal blackfin toolchain which has been removed
since because of lack of maintenance and testing.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we don't support the internal blackfin toolchain any more
remove unnecessary conditionals.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add fix for GCC PR 64896 from the gcc-4_9-branch of gcc.
This fixes bugzilla bug 7961.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The libcilk library (used on x86/x86-64 when building with C++ support)
unconditionally uses WCHAR_MIN / WCHAR_MAX, causing build issues with uClibc
when configured without wchar support.
Reported-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
Add support for AMD steamroller optimizations, available in gcc 4.8+ as
bdver3.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
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>
Versions older than GCC v4.9 do not support the Nios-II architecture
so disable them.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds a patch to gcc removing a unistd.h header include
in libgcc/config/nios2/linux-atomic.c
The file is built as part of GCC first stage (host-gcc-initial),
and so the header is not accesible. Given the header is not needed
it's fine to simply remove it.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now when new shiny tools are released by Synopsys we're ready for
version update in Buildroot again.
More details about arc-2014.12 release are available here:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2014.12
Following patches were removed from GCC since they are a part of release
now:
* 200-size_type_unsigned_int.patch
* 300-ptrdiff_type_int.patch
* 400-call-arc_hazard-before-branch-shortening.patch
* 401-fix-length-attribute-for-casesi_load-pattern.patch
* 402-fix-length-of-instructions-that-are-in-delay-slot-and-needs-to-be-predicated.patch
* 403-update-casesi_compact_jump-instruction-length.patch
But since arc-2014.12 tools are still based on GCC 4.8 following patches
ar still relevant so moving to the new folder to match ARC gcc bump.
* 100-libstdcxx-uclibc-c99.patch
* 910-gcc-poison-system-directories.patch
Binutils are still based on 2.23 so following patch still makes sense:
* 600-poison-system-directories.patch
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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 a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.
As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.
This also helps preparing the addition of other options to select
shared, shared+static or just static.
Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit enables the poison system directories option, which is now
available thanks to the gcc patches that have been added.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to gcc borrowed from CodeSourcery/Yocto that
warns about unsafe include paths (i.e /usr/include,
/usr/local/include, etc.). The patch was adapted to gcc 4.7.4, and
modified to support the BR_COMPILER_PARANOID_UNSAFE_PATH environment
variable to error out instead of just warn when unsafe paths are
used. Even though erroring out can be chosen by passing
-Werror=poison-system-directories, we are not sure this option in
CFLAGS will always be passed, so having an environment variable
guarantees it will always be passed, and also allows to have an
identical behavior to the external toolchain wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to gcc borrowed from CodeSourcery/Yocto that
warns about unsafe include paths (i.e /usr/include,
/usr/local/include, etc.). The patch was adapted to gcc arc-2014.08,
and modified to support the BR_COMPILER_PARANOID_UNSAFE_PATH
environment variable to error out instead of just warn when unsafe
paths are used. Even though erroring out can be chosen by passing
-Werror=poison-system-directories, we are not sure this option in
CFLAGS will always be passed, so having an environment variable
guarantees it will always be passed, and also allows to have an
identical behavior to the external toolchain wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to gcc borrowed from CodeSourcery/Yocto that
warns about unsafe include paths (i.e /usr/include,
/usr/local/include, etc.). The patch was adapted to gcc 4.8.3, and
modified to support the BR_COMPILER_PARANOID_UNSAFE_PATH environment
variable to error out instead of just warn when unsafe paths are
used. Even though erroring out can be chosen by passing
-Werror=poison-system-directories, we are not sure this option in
CFLAGS will always be passed, so having an environment variable
guarantees it will always be passed, and also allows to have an
identical behavior to the external toolchain wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to gcc borrowed from CodeSourcery/Yocto that
warns about unsafe include paths (i.e /usr/include,
/usr/local/include, etc.). The patch was adapted to gcc 4.9.1, and
modified to support the BR_COMPILER_PARANOID_UNSAFE_PATH environment
variable to error out instead of just warn when unsafe paths are
used. Even though erroring out can be chosen by passing
-Werror=poison-system-directories, we are not sure this option in
CFLAGS will always be passed, so having an environment variable
guarantees it will always be passed, and also allows to have an
identical behavior to the external toolchain wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
Freescale e5500 and e6500 cores are supported for versions >= 4.8
So filter out all of the older versions to avoid build failures.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove the fortran and objective C language support since these have
been deprecated since more than a year ago.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
That gcc series is old and is not used as the default version for
any of the architectures we support, so this commit gets rid of it.
[Thomas: move the Config.in.legacy option at the right location.]
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There is support for -mcpu=leon3 from gcc 4.8.3. Use this for LEON systems
instead of the non-mainline targets sparcsfleon, sparchfleon, sparcsfleonv8, and
sparchfleonv8.
[Thomas: add Config.in.legacy handling for the removed options.]
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Drop PR60102 patch which is now upstream.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
Since we switched to a two stage gcc build process, the AVR32
toolchain stopped building. This is because with such an old gcc
version, we cannot use the all-target-libgcc and install-target-libgcc
targets.
Before the two stage gcc, libgcc was only built in gcc-intermediate,
which carried a similar logic. This commit basically restores in
gcc-initial the logic that used to be in gcc-intermediate, which
consists in using the all-target-libcc and install-target-libgcc
targets only for gcc versions others than the AVR32 one.
Using the BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE option has a way of
distinguishing the old AVR32 compiler from the other gcc versions is a
bit ugly, but it's what was done in gcc-intermediate before. And since
the AVR32 support is due to go away at some point in the hopefully
near future, we don't care that much.
This will fix the build of the two AVR32 defconfig that have been
constantly failing since switching to the two stage gcc process.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Symptoms usually seen are like that:
--->---
Error: operand out of range (128 is not between -128 and 127)
--->---
where range may differ.
Since compiler tries to use jump/branch instructions with the shortest encoding
of offset it's important to calculate required offset properly.
In case of miscalculation by compiler later assembler throws an error because of
inability to encode requested value.
Fixes are taken from current development branch of GCC for ARC and will be a
part of the next release of ARC tools, so at that point patch should be dropped.
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>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.
This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.
Alignment of line continuation characters (\) is kept as-is.
The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'
Brief explanation of this command:
^\([A-Z0-9a-z_]\+\) a regular variable at the beginning of the line
\([?:+]\?=\) any assignment character =, :=, ?=, +=
\([^\\]\+\) any string not containing a line continuation
\([^\\ \t]\+\s*\\\) string, optional whitespace, followed by a
line continuation character
\(\s*\\\) optional whitespace, followed by a line
continuation character
Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.
This expression was tested on following test text: (initial tab not
included)
FOO = spaces before
FOO = spaces before and after
FOO = tab before
FOO = tab and spaces before
FOO = tab after
FOO = tab and spaces after
FOO = spaces and tab after
FOO = \
FOO = bar \
FOO = bar space \
FOO = \
GENIMAGE_DEPENDENCIES = host-pkgconf libconfuse
FOO += spaces before
FOO ?= spaces before and after
FOO :=
FOO =
FOO =
FOO =
FOO =
$(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
AT91BOOTSTRAP3_DEFCONFIG = \
AXEL_DISABLE_I18N=--i18n=0
After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
expression leaves the number of whitespace between the value and line
continuation character intact, but the whitespace before that could have
changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
actually makes the code more readable.
Finally, the end result was manually reviewed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_INSTALL_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_INSTALL_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>
While the autotools infrastructure was using FOO_MAKE_OPT, generic packages
were typically using FOO_MAKE_OPTS. This inconsistency becomes a problem
when a new infrastructure is introduced that wants to make use of
FOO_MAKE_OPT(S), and can live alongside either generic-package or
autotools-package. The new infrastructure will have to choose between either
OPT or OPTS, and thus rule out transparent usage by respectively generic
packages or generic packages. An example of such an infrastructure is
kconfig-package, which provides kconfig-related make targets.
The OPTS variant is more logical, as there are typically multiple options.
This patch renames all occurrences of FOO_MAKE_OPT in FOO_MAKE_OPTS.
Sed command used:
find * -type f | xargs sed -i 's#_MAKE_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>
This commit adds a new patch to the ARC 2014.08 gcc specific version,
that redefines PTRDIFF_TYPE from "long int" to "int".
The change of SIZE_TYPE from "long unsigned int" to "unsigned int"
http://git.buildroot.net/buildroot/commit/?id=0f236c1fef669192c8f5cc8ef26e93da91438dc2
introduced a regression due to the existing PTRDIFF_TYPE.
Now to fix regression the patch converts PTRDIFF_TYPE to simple "int".
The fix is taken from current development branch of GCC for ARC and
will be a part of the next release of ARC tools, so at that point
patch should be dropped.
846e92167a
[Thomas: tweak commit log.]
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cleanup arch/cpu combination limits, we had super-wide depends and it
doesn't help readability, version bumps or testing.
Make the bool/depends/select order the same for all entries.
Drop redundant limitations, for example sparc* if sparc wasn't
supported in general.
Power8 requires at least gcc 4.9.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With the kernel patch from:
http://patchwork.ozlabs.org/patch/384285/
There is no problem with latest gcc anymore.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This makes size_t to be "unsigned" ssize_t which makes happy compiler on data
type checks.
Fix is taken from current development branch of GCC for ARC and will be a
part of the next release of ARC tools, so at that point patch should be dropped.
249f040299
Fixes http://autobuild.buildroot.net/results/405/405da9a945511329929b18740b983c51b8dcc43e
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>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
Currently, the internal toolchain backend does a three stage gcc
build, with the following sequence of builds:
- build gcc-initial
- configure libc, install headers and start files
- build gcc-intermediate
- build libc
- build gcc-final
However, it turns out that this is not necessary, and only a two stage
gcc build is needed. At some point, it was believed that a three stage
gcc build was needed for NPTL based toolchains with old gcc versions,
but even a gcc 4.4 build with a NPTL toolchain works fine.
So, this commit switches the internal toolchain backend to use a two
stage gcc build: just gcc-initial and gcc-final. It does so by:
* Removing the custom dependency of all C libraries build step to
host-gcc-intermediate. Now the C library packages simply have to
depend on host-gcc-initial as a normal dependency (which they
already do), and that's it.
* Build and install both gcc *and* libgcc in
host-gcc-initial. Previously, only gcc was built and installed in
host-gcc-initial. libgcc was only done in host-gcc-intermediate,
but now we need libgcc to build the C library.
* Pass appropriate environment variables to get SSP (Stack Smashing
Protection) to work properly:
- Tell the compiler that the libc will provide the SSP support, by
passing gcc_cv_libc_provides_ssp=yes. In Buildroot, we have
chosen to use the SSP support from the C library instead of the
SSP support from the compiler (this is not changed by this patch
series, it was already the case).
- Tell glibc to *not* build its own programs with SSP support. The
issue is that if glibc detects that the compiler supports
-fstack-protector, then glibc uses it to build a few things with
SSP. However, at this point, the support is not complete (we
only have host-gcc-initial, and the C library is not completely
built). So, we pass libc_cv_ssp=no to tell the C library to not
use SSP support itself. Note that this is not a big loss: only a
few parts of the C library were built with -fstack-protector,
not the entire library.
* A special change is needed for ARC, because its libgcc depends on
the C library, which breaks building libgcc in
host-gcc-initial. This looks like a bug in the ARC compiler, as it
does not obey the inhibit_libc variable which tells the compiler
build process to *not* enable things that depend on the C
library. So for now, in host-gcc-initial, we simply disable the
build of libgmon.a for ARC. It's going to be built as part of
host-gcc-final, so the final compiler will have gmon support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now when new shiny tools are released by Synopsys we're ready for version
update in Buildroot.
Important change in this release is switching to combined "binutils-gdb" repo
in accordance to upstream move.
Following patch now is a part of the most recent relese:
e6ab8cac62
So dropping it.
package/binutils/arc-4.8-R3/0001-arc-Honor-DESTDIR-in-custom-Makefile.patch
Since arc-2014.08 tools are still based on GCC 4.8 following patch is still
relevant so moving to the new folder to matxh ARC gcc bump.
package/gcc/arc-4.8-R3/100-libstdcxx-uclibc-c99.patch ->
package/gcc/arc-2014.08/100-libstdcxx-uclibc-c99.patch
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>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following the introduction of the support for the musl C library, the
support of C++ exceptions or features like pthread_exit() got broken
even with other libraries such as glibc. This was reported as bug #7028.
The problem was caused by the gcc patch needed to add support for
musl, which modified the libgcc/unwind-dw2-fde-dip.c logic to decide
whether USE_PT_GNU_EH_FRAME should be enabled or not. It completely
removed the existing logic, replacing it by a single logic based on
the definition of TARGET_DL_ITERATE_PHDR. However, this constant gets
defined by the configure script only for Solaris, or Linux Musl
platforms. For glibc/uClibc, the configure script does not define it,
and therefore USE_PT_GNU_EH_FRAME is not defined, causing issues with
exception handling.
This patch fixes that by restoring all the logic of
libgcc/unwind-dw2-fde-dip.c, and just adding the musl logic as one
more case.
It has been successfully runtime tested using the two code examples
provided in bug #7208, with uClibc, musl and glibc.
Cc: Krzysztof Wrzalik <kwrzalik@gmail.com>
Cc: David Bachelart <david.bachelart@bbright.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following the introduction of the support for the musl C library, the
support of C++ exceptions or features like pthread_exit() got broken
even with other libraries such as glibc. This was reported as bug #7028.
The problem was caused by the gcc patch needed to add support for
musl, which modified the libgcc/unwind-dw2-fde-dip.c logic to decide
whether USE_PT_GNU_EH_FRAME should be enabled or not. It completely
removed the existing logic, replacing it by a single logic based on
the definition of TARGET_DL_ITERATE_PHDR. However, this constant gets
defined by the configure script only for Solaris, or Linux Musl
platforms. For glibc/uClibc, the configure script does not define it,
and therefore USE_PT_GNU_EH_FRAME is not defined, causing issues with
exception handling.
This patch fixes that by restoring all the logic of
libgcc/unwind-dw2-fde-dip.c, and just adding the musl logic as one
more case.
It has been successfully runtime tested using the two code examples
provided in bug #7208, with uClibc, musl and glibc.
Cc: Krzysztof Wrzalik <kwrzalik@gmail.com>
Cc: David Bachelart <david.bachelart@bbright.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following the introduction of the support for the musl C library, the
support of C++ exceptions or features like pthread_exit() got broken
even with other libraries such as glibc. This was reported as bug #7028.
The problem was caused by the gcc patch needed to add support for
musl, which modified the libgcc/unwind-dw2-fde-dip.c logic to decide
whether USE_PT_GNU_EH_FRAME should be enabled or not. It completely
removed the existing logic, replacing it by a single logic based on
the definition of TARGET_DL_ITERATE_PHDR. However, this constant gets
defined by the configure script only for Solaris, or Linux Musl
platforms. For glibc/uClibc, the configure script does not define it,
and therefore USE_PT_GNU_EH_FRAME is not defined, causing issues with
exception handling.
This patch fixes that by restoring all the logic of
libgcc/unwind-dw2-fde-dip.c, and just adding the musl logic as one
more case.
It has been successfully runtime tested using the two code examples
provided in bug #7208, with uClibc, musl and glibc.
Cc: Krzysztof Wrzalik <kwrzalik@gmail.com>
Cc: David Bachelart <david.bachelart@bbright.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes bug #7250, by allowing more libstdc++ features to be
enabled with uClibc. libstdc++ wants an absolutely complete C99
support in the C library before enabling *any* feature that needs some
C99 functions. However, uClibc doesn't provide C99 complex numbers, so
libstdc++ disables a lot of C++ standard methods, even though they are
not related to C99 complex numbers.
A partial solution already existed in the patch
302-c99-snprintf.patch, but this commit replaces it by the more
complete 850-libstdcxx-uclibc-c99.patch, which is highly inspired by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393, except that it
doesn't rely on configure.ac checks, but simply on testing
defined(__UCLIBC__) like was done in 302-c99-snprintf.patch. This
allows to avoid having to autoreconf gcc, which is quite complicated
to achieve.
Reported-by: Richard <tarka.t.otter@gmail.com>
Cc: Richard <tarka.t.otter@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes bug #7250, by allowing more libstdc++ features to be
enabled with uClibc. libstdc++ wants an absolutely complete C99
support in the C library before enabling *any* feature that needs some
C99 functions. However, uClibc doesn't provide C99 complex numbers, so
libstdc++ disables a lot of C++ standard methods, even though they are
not related to C99 complex numbers.
A partial solution already existed in the patch
302-c99-snprintf.patch, but this commit replaces it by the more
complete 850-libstdcxx-uclibc-c99.patch, which is highly inspired by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393, except that it
doesn't rely on configure.ac checks, but simply on testing
defined(__UCLIBC__) like was done in 302-c99-snprintf.patch. This
allows to avoid having to autoreconf gcc, which is quite complicated
to achieve.
Reported-by: Richard <tarka.t.otter@gmail.com>
Cc: Richard <tarka.t.otter@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes bug #7250, by allowing more libstdc++ features to be
enabled with uClibc. libstdc++ wants an absolutely complete C99
support in the C library before enabling *any* feature that needs some
C99 functions. However, uClibc doesn't provide C99 complex numbers, so
libstdc++ disables a lot of C++ standard methods, even though they are
not related to C99 complex numbers.
A partial solution already existed in the patch
302-c99-snprintf.patch, but this commit replaces it by the more
complete 850-libstdcxx-uclibc-c99.patch, which is highly inspired by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393, except that it
doesn't rely on configure.ac checks, but simply on testing
defined(__UCLIBC__) like was done in 302-c99-snprintf.patch. This
allows to avoid having to autoreconf gcc, which is quite complicated
to achieve.
Reported-by: Richard <tarka.t.otter@gmail.com>
Cc: Richard <tarka.t.otter@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
