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>
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>
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>
Include the gnuprumcu package in PRU cross toolchain.
Toolchain is somewhat useless without device specs and
linker scripts for the various SoCs.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Add sample configuration for building cross toolchain for the TI PRU.
PRU cores are present in many of the BeagleBone single board computers.
More information about the PRU can be found in https://bbb.io/pru
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
This allows building newlib-nano in addition to newlib and picolibc,
allowing users to select between C libraries within the same toolchain.
Signed-off-by: Keith Packard <keithp@keithp.com>
This adds another mode to do_gcc_core_backend that builds libstdc++
against an alternate libc implementation.
Signed-off-by: Keith Packard <keithp@keithp.com>
Currently when building cross-canadian toolchain for macOS
the folowing error happens when GCC is configured:
|ld: illegal text-relocation to '___gmp_binvert_limb_table' in
|... /.build/... /buildtools/complibs-host/lib/libgmp.a(mp_minv_tab.o) from '___gmpn_divexact_1' in
|... /.build/... /buildtools/complibs-host/lib/libgmp.a(dive_1.o)
|collect2: error: ld returned 1 exit status
Apparently this might be solved with GMP configured with "--with-pic",
even though we're talking about static library here.
That solution was found here:
https://github.com/Homebrew/homebrew-core/pull/25470
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Even though GCC as a compiler has nothing to do with a C library
being used it still makes sense to know about Newlib's compact
implementation of IO functions:
* For targets like MSP430 which require to have such a tuned
Newlib if "-mtiny-printf" is passed to the GCC's command-line [1]
* For correct compilation of the following GCC's own DejaGnu tests [2]:
- gcc/testsuite/gcc.c-torture/execute/920501-8.c
- gcc/testsuite/gcc.c-torture/execute/930513-1.c
- gcc/testsuite/gcc.dg/torture/builtin-sprintf.c
- gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=02afb6a9321fbfb435452636cedc2cd43f0c4fd2
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=571bbd0d48d5872eacbd0b681fce6e1ae754520b
So we add that missing cross-dependency now.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Similar to commit 57679b5e ("Disable context functions for Thumb") when
building for thumb we need to unset UCLIBC_HAS_CONTEXT_FUNCS.
Fixes#1397
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Since glibc 2.27 glob interface was changed [1] and so
"glob" & "glob64" symbols require glibc 2.27+.
For us that means if we build Binutils on a machine with glibc 2.27+
produced binaries won't be any longer usable on machines with older
glibc.
As an example [2]: build on Ubuntu 18.04 (with glibc 2.27) and try to run
on CentOS 7.x (with glibc 2.17), you'll see this:
---------------------->8-------------------
ldd ld
ld: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by ld)
---------------------->8-------------------
Now given glob is not really used by Binutils itself (only needed by GDB)
and we build Binutils & GDB separately let's make at least Binutils
more portable.
In theory we may even try to do the same hack for GDB forcing it to use
imported glob implementation. But since GDB is now built strictly by C++
compiler we'll get waaay to many incompatibilities due to multiple changes
of C++ ABI in between GCC 7.5 of Ubuntu 18.04 and GCC 4.8.5 of CentOS 7.x,
so there's no point to even try.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=ccf970c7a77e86f4f5ef8ecc5e637114b1c0136a
[2] https://github.com/zephyrproject-rtos/sdk-ng/issues/280
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
While building a canadian toolchain for windows host (any target),
the build failed for m4 host companion_tool with a recent mingw-w64
(at least 7.0.0).
m4 needs stack smashing protection which is not part of mingw-w64 c
library and an explicit trigger to link w/ libssp is needed.
Signed-off-by: Florent Valette <florent.valette@gmail.com>
By setting glibc build system default_cflags to be empty before
building, we will enforce the build system to only use the crosstool-ng
CFLAGS when building glibc.
Properly solves the issue identified in #1396.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
picolibc is another bare-metal C library, and so should be mapped
to CT_TARGET_SYS just like newlib does.
Signed-off-by: Keith Packard <keithp@keithp.com>
This adds support for using picolibc instead of newlib on embedded
systems.
Signed-off-by: Keith Packard <keithp@keithp.com>
v2:
Add check for meson and ninja
Sync option default values with current picolibc defaults
Remove xtensa sys header file install as those aren't in picolibc
This commit updates the GDB build script to specify `-static-libgcc`
when `CT_GDB_NATIVE_STATIC_LIBSTDCXX` is enabled. Both libgcc and
libstdc++ are considered to be part of the "standard libraries," and
should be specified by the same flag (the configuration symbol could
potentially use a better name and/or further indirection).
This also semantically aligns the `CT_GDB_NATIVE_STATIC_LIBSTDCXX`
with the equivalent GCC configuration `CT_CC_GCC_STATIC_LIBSTDCXX`,
which also enables static linking of both libgcc and libstdc++.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit fixes an incorrect reference to the configuration
`CT_GDB_NATIVE_STATIC_LIBSTDCXX` in the GDB build script.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
-- c6x: Add support for c6x product families to pass on to uClibC-ng
-- c6x: Fix multilib support
-- c6x: Add patch fix internal instruction error (GCC 57295)
Signed-off-by: Dan Tejada <dan.tejada@cantada.com>
GLIBC 2.31 needs --with-cpu=ultrasparc for both 32/64-bits now, and
--with-cpu only sets the CPU model for the "primary" bitness.
Signed-off-by: Alexey Neyman <stilor@att.net>
This commit adds support for the newlib configuration option
'--enable-newlib-retargetable-locking'.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
I was trying to build static binaries for a range of Broadcom soft-float ARMv7
SoCs and kept getting SIGILL, although I was targeting Cortex A7 (and A5,
later), even on A9 and A15.
I found out that once I add -msoft-float, +mp+sec is to blame:
Attribute Section: aeabi
File Attributes
- Tag_CPU_name: "7VE"
+ Tag_CPU_name: "7"
Tag_CPU_arch: v7
- Tag_CPU_arch_profile: Application
- Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
@@ -12,8 +10,5 @@ File Attributes
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_optimization_goals: Aggressive Size
Tag_CPU_unaligned_access: v6
- Tag_MPextension_use: Allowed
- Tag_DIV_use: Allowed in v7-A with integer division extension
- Tag_Virtualization_use: TrustZone and Virtualization Extensions
(This is the readelf -A diff, before and after armv7-a+nofp -> armv7+nofp).
I kept getting SIGILL even after building my application with a toolchain built
with the correct CFLAGS and found out that crosstool-ng doesn't pass the host
CFLAGS when building musl, which pollutes my binary with these ARMv7 extensions.
Signed-off-by: Dima Krasner <dima@dimakrasner.com>
The glibc will append the content of the CFLAGS variable,
overriding previous flags.
If unset, the CFLAGS variable is not empty, so explicitly set it.
Instead prepend the default CFLAGS flags.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
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>
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>
... 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>
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>
... when it is compiled without the native GDB.
Also, fix the gdbserver to be installed without a program prefix in this
case, as it was before the unification of the GDB backend.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Force building make as a companion tool if host make is older than
4.0 (CentOS 7 currently has 3.82)
- Disable 2.29 as a choice if host python is older than 3.4
(CentOS 7 has 2.6 unless python from EPEL is installed)
- Python2 emits its version information to STDERR. Ugh.
While there, also use the detected host Python for GDB configuration.
Signed-off-by: Alexey Neyman <stilor@att.net>
This fixes following build error on Debian 9:
configure: error: Your local docbook2man was found to work with SGML rather
than XML. Please install docbook2X and use variable DOCBOOK_TO_MAN to point
configure to command docbook2x-man of docbook2X.
Or use DOCBOOK_TO_MAN="xmlto man --skip-validation" if you have xmlto around.
You can also configure using --without-docbook if you can do without a man
page for xmlwf.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
uClibc-ng 1.0.31 enabled FDPIC as an option for ARM/no-MMU
configurations and defaults to that option if not set explicitly.
Signed-off-by: Alexey Neyman <stilor@att.net>
... in the backend function with ${CFLAGS_FOR_HOST}. The caller either
supplies them already, or (in case of pass-1/2 of the canadian cross)
passes ${CFLAGS_FOR_BUILD} there.
Signed-off-by: Alexey Neyman <stilor@att.net>
Otherwise, glibc 2.29 tries to use it - but we haven't built libstdc++ yet.
We really need to implement #808... Until now, pass empty CXX to make.
Signed-off-by: Alexey Neyman <stilor@att.net>
... which, after a recent change, is not reflected into CT_ALL_TARGET_CFLAGS
for non-multilib configurations.
Signed-off-by: Alexey Neyman <stilor@att.net>
... parts of the config tuple. While here, remove parts that are
setting portions of the target tuple to a value that's already
the default.
Signed-off-by: Alexey Neyman <stilor@att.net>
... in uClibc and glibc.
Fixes#681.
While here, relocate additional "sources" for uClibc/binutils into packages/
directory.
Signed-off-by: Alexey Neyman <stilor@att.net>
This required some rework of the libc selection, as moxiebox is a layer on
top of another libc - newlib.
Also, moxiebox'es host VM (`sandbox`) needs a libcrypto on the host. We will
not have it if we're cross-compiling a canadian cross. Fortunately, all moxiebox
needs from libcrypto is SHA256, and it already includes a standalone implementation
of SHA256 in its runtime. Provide a little wrapper that allows moxiebox use
that implementation for the host binary, too.
Also, automate collecting/printing the list of all packages in a given category
(e.g. LIBC or COMP_TOOLS), generate a list of all Kconfig symbols for a given
category.
Signed-off-by: Alexey Neyman <stilor@att.net>
... and use that ability to permanently set CTNG_LD_IS in case gold is default linker
and we're building glibc.
Fixes#988. This was a long-standing breakage in crosstool-NG (at least since it began
to run each step in a sub-shell).
Signed-off-by: Alexey Neyman <stilor@att.net>
