So again due to non-technical reasons (lack of public documentation
of ARC instruction set which we actively work on but no yet published)
we missed upstream 2.30 release.
Still the code is there, we regularly run full test-suite and are confident
in port's quality and robustness.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Fixes: #1210
Per the release notes for the GNU C library 2.28[1] make 4.0 or newer is
required. Previously the logic was applied to glibc 2.29 or newer.
[1] - https://www.sourceware.org/ml/libc-alpha/2018-08/msg00003.html
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Currently, SourceForge is down and downloads give a 500 error. That's
not overly uncommon (even less often the case these days). Fortunately,
zlib provides another mirror on their homepage, add that as option to
the package description. (https://www.zlib.net/)
Forward ported patches from GCC 8.3.0 to 9.2.0, refreshed to match
current sources.
In patch 0012-crystax.patch, removed changing sysv4.h header file for
rs6000, since it no longer defines LINK_EH_SPEC.
Removed the following patches because they are part of upstream:
- 0018-ARC-Add-multilib-support-for-linux-targets.patch
- 0020-ARM-fix-cmse.patch
- 0021-arm-Make-arm_cmse.h-C99-compatible.patch
- 0022-ARC-Update-fma-expansions.patch
Renamed 0019-isl-0.20.patch => 0018-isl-0.20.patch.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
From GCC's standpoint ARC's multilib items are defined by "mcpu" values
which we have quite a few and for all of them might be built optimized
cross-toolchain.
From Glibc's standpoint multilib is just multi-ABI [1] and so very limited
versions are supposed to co-exist (e.g. arc700 & archs).
Here we force Glibc to install libraries in GCC's multilib folder to create
a universal cross-toolchain that has libs optimized for multiple CPU types.
But note we only need to mess with installation paths in case of real
multilib, otherwise we keep default "lib/" paths so that GCC finds default
(the one and only) libs where it expects them to be.
Also here we add a sample which allows to build universal Glibc Linux
toolchain for ARC.
[1] https://sourceware.org/ml/libc-alpha/2019-06/msg00018.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
ARC port of Glibc was submitted to the mailing list recently [1]
but due to late submission it didn't make it in Glibc 2.29 release.
Hopefully by the time of next release it will be a part of upstream
release but for now we have to use off-the-tree patch.
Still it's proven to work internally as well as its test-suite
shows brilliant results as might be seen from [1]:
------------------>8-------------------
Summary of test results:
24 FAIL
5124 PASS
27 UNSUPPORTED
19 XFAIL
------------------>8-------------------
Moreover ARC's Glibc port is known to work in Buildroot, OpenEmbedded
and even Automotive Grade Linux distro so we should be good having
this patch for Glibc.
BTW the patch itself is a copy of the one I use in OE, see [2].
[1] https://sourceware.org/ml/libc-alpha/2018-12/msg00678.html
[2] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/recipes-core/glibc/files/0031-Add-ARC-architecture.patch
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
While we may use build machine's library when building a simple cross,
we won't have it for the host machine in a canadian build. Until there
are separate selectables for the build/host components, just build our
own local zlib.
Signed-off-by: Alexey Neyman <stilor@att.net>
... resulted in an attempt to build libinproctrace.so whenever any
of the {gdbserver, native gdb} was enabled.
Signed-off-by: Alexey Neyman <stilor@att.net>
G+ is now defunct, update the reporter_url to bootlin as both Thomas and I
are working there.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
uclibc_backend_once tries to build dummy shared libraries regardless of
whether shared libraries support for target is enabled or not, resulting
in build failure in noMMU bFLT configuration.
Only build dummy shared libraries when shared library support for target
is enabled.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
scripts/build/kernel/linux.sh only provides suffix to known
architectures when building toolchain targeting noMMU linux.
Add support for xtensa and assign uclinux suffix to it.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
We've had very solid support for C++ for quite a while now in RISC-V
land, at least in our Linux targets. This patch set enables C++ support
by default, which I assume most users will want.
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
... which fixes <panel.h> detection on Alpine Linux (which has ncursesw
but installs it into plain /usr/include).
Signed-off-by: Alexey Neyman <stilor@att.net>
