Fetch in various patches from binutils-2_37-branch upstream.
The most vital change is the
0012-pr28391-strip-objcopy-preserve-dates-a-cannot-set-time.patch which
allows building large upstream projects like Qt WebEngine without need
100k's of file descriptors open.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
The patch in question was first introduced in [1] as a copy-paste
from OpenEmbedded [2], where it seems to exist on the first ever SVN commit.
Later it was removed from OE in [3] on switching to Binutils 2.25.
It's not clear why it was introduced in the first place and why it
got removed later. But given in OE/Yocto it was missing since 2015
and never was reverted, I guess it is not strictly necessary
at least with recent Binutils. So it's an extra patch which adds
questionable value. Moreover it gets in the way if one wants to
merge a couple of separate toolchains like little- & big-enadian
so that "bin" & "lib" folder contain all the binaries and libs
simultaneously. W/ that patch in place ldscripts won't co-exist,
but instead the latest set of scripts will override all the rest.
And in case of aforementioned example w/ merged little- &
big-endian toolchains BE ldscripts will override LE ones leading
to a funny behavior: on linking w/o explicitly set endianess
(via "-EL" or "-EB") default linker scripts won't match the GCC driver
used:
------------------------------->8---------------------------
$ arc-elf32-gcc test.c -Wl,-marcv2elfx
...
.../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/bin/ld: .../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/lib/crt0.o: compiled for a little endian system and target is big endian
.../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/bin/ld: failed to merge target specific data of file .../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/lib/crt0.o
.../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/bin/ld: .../bin/../lib/gcc/arc-snps-elf/11.2.0/crti.o: compiled for a little endian system and target is big endian
...
------------------------------->8---------------------------
[1] cfbcdd3786
[2] 4b46c1f6e8
[3] 3c7fe424f8
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This fixes a defect introduced in 25162c7. The "uint" type has not
been explicitly defined here on mingw, causing compilation to fail.
Signed-off-by: Artem Panfilov <artemp@synopsys.com>