In currently generated top-level "nano.specs" we resolve
paths during toolchain building and then use those pre-defined
full paths once the toolchain got built.
That's OK until the toolchain is used right were it was built,
otherwise paths used in the top-level "nano.specs" become
irrelevant and linker fails to find "nano" libs reverting to
non-"nano" libs in the default location.
See https://github.com/crosstool-ng/crosstool-ng/issues/1491.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Add an option that will install a copy of newlib-nano lib*.a file in
the target dir but renamed with a nano.a suffix (eg: libc_nano.a) as
some default nano.spec files from newlib expect this setup.
Additionally the newlib-nano version of newlib.h will get copied to
include/newlib-nano/newlib.h.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Some really old GDB releases did have gdbserver's configure
script w/o execution permissions, so there was a need in the fix.
As per Yann most likely it could have been true for GDB versions in
between v5.3 & 6.6. Moreover it could have been fixed on re-release
of GDB tarballs done in 2011, see [1].
And given we no longer support such old GDB versions in CT-NG
(as of today we have 6.8 - 9.2, moreover it's not clear which of
6.8-7.x versions are still being actively used) we'll revert that old hack
for now in a hope that it won't hurt anybody.
Though if somebody sees that problem again
we'll be able to revert this again ;)
[1] https://sourceware.org/legacy-ml/gdb/2011-09/msg00002.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Newer versions of GCC complain:
plt.c: In function 'arch_elf_add_plt_entry':
plt.c:359:3: error: '%s' directive argument is null [-Werror=format-overflow=]
359 | fprintf(stderr, "%s: failed %s(%#llx): %sn", __func__,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
360 | name, addr, strerror(errno));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
add a patch to avoid this error.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Similar to commit ca45a8f9 ("Add -D__GLIBC__ to target CFLAGS") newer
versions of strace bundle the kernel headers which cause build errors
such as:
[ALL ] In file included from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/bundled/linux/include/uapi/linux/in6.h:26,
[ALL ] from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/bundled/linux/include/uapi/linux/if_bridge.h:19,
[ALL ] from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/src/rtnl_mdb.c:16:
[ERROR] /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/bundled/linux/include/uapi/linux/libc-compat.h:109: error: "__UAPI_DEF_IN6_ADDR_ALT" redefined [-Werror]
[ALL ] 109 | #define __UAPI_DEF_IN6_ADDR_ALT 1
[ALL ] |
[ALL ] In file included from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/src/rtnl_mdb.c:15:
[ALL ] /home/x-tool/x-tools/arm-unknown-linux-musleabi/arm-unknown-linux-musleabi/sysroot/usr/include/netinet/in.h:401: note: this is the location of the previous definition
[ALL ] 401 | #define __UAPI_DEF_IN6_ADDR_ALT 0
[ALL ] |
[ALL ] cc1: all warnings being treated as errors
By defining __USE_MISC we get __UAPI_DEF_IN6_ADDR_ALT defined in a
compatible manner.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
sh-multilib-linux-gnu ends up building 8 different libcs. This seems to
be problematic for the github hosted runners as it appears to run them
out of disk space (anecdotally this seems to have gotten worse with the
switch from ubuntu-18.04 to ubuntu-20.04).
Build sh-unknown-elf instead to make sure we cover of the sh
architecture to some degree.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
If existing board's .specs are used for linking of a user's application,
then instead of normally used libs like libc.a & libstdc++.a might be
requested their "nano"-suffixed siblings: libc_nano.a, libstdc++_nano etc.
That way:
----------------------------->8---------------------------
%rename link_gcc_c_sequence myboard_link_gcc_c_sequence
*myboard_libc:
%{!specs=nano.specs:-lc} %{specs=nano.specs:-lc_nano}
*link_gcc_c_sequence:
%(myboard_link_gcc_c_sequence) --start-group %G %(myboard_libc) --end-group
----------------------------->8---------------------------
Our companion newlib-nano libs are all built optimized for size, so we'd like
to use them for linking. But given linker will see "-lc_nano -lstdc++_nano"
on its command line non-suffixed libs will be ignored.
To solve it we create those "_nano"-suffixed libraries as simple symlinks to
existing libs..
Fixes https://github.com/crosstool-ng/crosstool-ng/issues/1458.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
As of today baremetal (AKA "Elf32") & Linux glibc toolchains are even
more important than Linux uClibc one for ARC, so adding them.
We exclude ARC Linux toolchains from Mac buils as it seem to not make
much sense and anyway glibc build for ARC700 fails,
see https://github.com/crosstool-ng/crosstool-ng/pull/1456#issuecomment-779150246
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
As of today ARCompact (AKA "ARCv1 ISA") processors (mostly those are ARC770)
are not officially supported by upstream glibc as it adds quite some burden
on release ans support of yet another "architecture" port.
But given on ABI and ISA front ARCompact is very close to ARCv2 we may
easily retrofit its support off-the-tree, which we do here.
Also given amount of changes we need to apply there's a hope it will be easy
and straight-forward to apply the same to later versions of glibc.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The kconfig update has pulled in a change creating a top level include/
directory, ignore this from git perspective to avoid mis-committing.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
