Two patches from 0.18.8.1 were dropped:
- one changing the declaration of environ is no longer needed, the
corresponding files no longer have this declaration
- one with Woe32 fixes for -O0 may need to be re-added but only after I
find what configuration breaks without it; gettext sources overwent a
massive restructuring so this patch should not be applied without
testing.
Signed-off-by: Alexey Neyman <stilor@att.net>
Fixes: #887
On some systems the file command identifies a pie executable as a shared
object. Update do_finish() to handle this case so that they are stripped
as well.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
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>
