With libc_headers step before pass-1, there is no need to distinguish
pass-1 and pass-2; they are configured identically (note that with the
current configuration, core pass-2 is only used for win32 - hence, uses
build_libgcc=yes and mode=static).
Signed-off-by: Alexey Neyman <stilor@att.net>
After 557b9d4, libc_start_files and libc_main steps are performed one
after another. It doesn't make sense, especially since some of the libcs
(glibc, uClibc-ng) go to great lengths to first install start files in
the first step, libc_start_files, only to remove them immediately in the
second step, libc_main.
Current build steps also break in the xtensa newlib configurations, as
it needs to install the custom xtensa headers before building the libgcc
and after 557b9d4, the headers are not installed before libgcc is built
in pass-1.
Therefore, finish what 557b9d4 mentioned but did not do: move header
installation into a new step, libc_headers, and combine libc_start_files
and libc_main into a single step.
This also allows to combine the core pass-1/pass-2 steps, to be done in
a subsequent commit.
Signed-off-by: Alexey Neyman <stilor@att.net>
... and the code dependent on them, after the latest wave of obsolete
package removals. This concludes the glorious history of the original
uClibc (non-NG) with lots of kludges removed.
There was a choice here, whether to call the resulting libc "uClibc" or
"uClibc-ng". I opted in favor of giving uClibc-ng the recognition it
deserves, although it had some ripple effect in the ct-ng code.
Signed-off-by: Alexey Neyman <stilor@att.net>
Per https://github.com/crosstool-ng/crosstool-ng/issues/808 build static
libgcc in the first pass which lets us skip the second one. Building
mingw-w64 requires header files in order to build C++ support so mingw
builds core pass 2. This could probably be cleaned up by splitting
libc_start_files into a separate libc_header step. But for now having
core 2 for mingw-w64 and core 1 for the other libcs will have to do.
Anything that previously selected CC_CORE_PASSES_NEEDED now selects
CC_CORE_PASS_1_NEEDED. The same goes for CC_CORE_PASS_2_NEEDED with the
exception of mingw-w64.
Fixes#808Fixes#217
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- binutils-linaro-2.23.2-2013.10-4
- binutils-linaro-2.24.0-2014.11-2
- binutils-linaro-2.25.0-2015.01-2
- binutils-2.23.2
- binutils-2.24
- binutils-2.25.1
Adjust the milestones now that the old versions have been removed.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Now that the oldest supported version of gdb is 7.11.1 we can make some
parts of the build unconditional and remove the associated config vars.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Back in the day gdbserver was treated as a subproject of GDB and
even was located in "gdb/gdbserver" and so to build gdbserver we had
to go into "gdb/gdbserver" and there run configure. That way full GDB
was out of the picture.
Now starting from GDB 10.1 where gdbserver was promoted to the top-level
we're supposed to run top-level's configure script for all the tools
provided by the unified binutils-gdb tree.
That said if we only want to build gdbserver (and that's what we
want since we build one tool at a build step) we have to be explicit:
----------------->8----------------
--enable-gdbserver --disable--gdb
----------------->8----------------
Ah, and so far we used to build full native GDB when only wanted gdbserver
if it was GDB v10.x ;)
Ironically full native/target GDB also enabled gdbserver by default so
we need to also disable it explicitly with "--disable-gdbserver".
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Since we have curses built for target anyway now, why don't allow
users to use very convenient pseudo-GUI operating mode?
And while at it, there's no use of TUI in naturally headless gdbserver.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
"--with-host-libstdcxx" option was removed in GCC 6.x, see [1] because of [2].
So it makes no sense to use it with later GCC versions.
Frankly I don't like that implementation with yet another set of "if XXX",
but since we still support GCC down to 4.8.5 what else we may do?
Well, technically we may keep using things as they are now,
because surprisingly GCC's configure script doesn't mind accepting
meaningless options, but as a person who's looking at differences between
various builds and drill-down to peculiarities of various config
options, I'd prefer to not pollute configure with garbage.
But for all the rest... well, it works now and maybe nodody else cares.
[1] https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=5dc85f7ec719a79ecfbcdd8563b07e5f0f365e65
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
GCC 11+ requires compiler being used to support C++11 standard [1].
And while GCC starting from 6.x has C++11 support enabled by default [2],
older versions need to be forced to implement it with "-std=gnu++11" and luckily
GCC's build-system takes care of that:
1. For ${host} compiler - [1]
2. For ${build} compiler - [3, 4]
In a nutshell the configure script tries a couple of options and the one which
helps to build a test source gets appended to CXX (not CXXFLAGS!),
so on say CentOS 7.x with GCC 4.8.5 during cross-compilation of GCC
CXX="x86_64-build_pc-linux-gnu-g++ -std=gnu++11". And all is good.
But in case of canadian cross due to [5] we for some reason* force set
CXX_FOR_BUILD with just a compiler name, effectively overriding all the
magic done by GCC's internals described above.
This leads to a compilation failures like that:
------------------------------------->8----------------------------------
[ALL ] In file included from /usr/include/c++/4.8.2/type_traits:35:0,
[ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/system.h:244,
[ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/gengtype.c:26:
[ERROR] /usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
[ALL ] #error This file requires compiler and library support for the ^
------------------------------------->8----------------------------------
* my guess that [5] was done because back in the day indeed we used to have
"--build=${CT_BUILD} --host=${CT_HOST}" in do_cc_core(). But now after [6]
this is no longer necessary as we use "--build=${CT_BUILD} --host=${CT_BUILD}"
and all is safe and clean. So yet another old quirk goes away - hooray!
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5329b59a2e13dabbe2038af0fe2e3cf5fc7f98ed
[2] https://gcc.gnu.org/gcc-6/changes.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612
[4] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7ffcf5d61174dda1f39a623e15f7e5d6b98bbafc
[5] 9c6c090d7b
[6] 08161250ed
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
GCC can support using zstd compression for LTO object files. By default
GCC's configure will enable this if libzstd is installed on the machine
building the toolchain. This may be undesirable if the toolchain is to
be used on a different machine. Add an option to control zstd usage and
set the default to the same as the current behaviour (i.e. auto).
Fixes#1579
Signed-off-by: Chris Packham <judge.packham@gmail.com>
In GDB 10.x gdbserver was promoted to the top-level folder,
see https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=919adfe8409211c726c1d05b47ca59890ee648f1
Which means it is no longer a subfolder in "gdb" and so we have to
build gdbserver now exactly in the same way as normal native GDB.
One interesting detail is gdbserver doesn't need to deal with target
description in .xml so it doesn't depend on libexpat on target,
thus we need to move libexpat explicit selection from do_gdb_backend()
to its callers when building native [full] gdb as well as cross-gdb
for the host.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
[cp: support old/new layout, regenerate patches]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Older ARC700 processors had atomic instructions (AKA llock/scond)
as an option and so quite some "atomic" operations were not possible
w/o OS support, which we implemented - see arc_usr_cmpxchg() in the
Linux kernel.
And in uClibc, which was the only Linux libc back in the day of ARC700
era, it is well supported. Well, uClibc could be configured to support it.
Which is done with CONFIG_ARC_HAS_ATOMICS Kconfig option.
But the problem is there's no check for ARC ISA version in uClibc when
this option gets enabled. That leads to a funny situation when even for
ARCv2 processors (ARC HS3x & HS4x) uClibc tries to utilize
arc_usr_cmpxchg() syscall which is not supported for this newer ISA since
ARCv2 processors have atomic instructions built-in all the time.
So what was happening here we didn't specify additional "-matomic"
CFLAG unless we were targeting exactly those ancient ARC770 processors
(ARC700 + MMUv3 + atomics) and so even for ARCv2 we forced uClibc
to not use built-in atomics.
And even though there're ways to add a smarter solution here to handle
that pretty rare by now case of ARC750 (ARC700 + MMUv2 - atomics),
I suggest we just remove this part completely, leaving a possibility
to add needed option in uClibc-ng's configuration
(I mean "packages/uClibc-ng/config").
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Changes since v0.5.0:
* Add spec files for am64x SoCs.
* Require Binutils at least version 2.37.
* Require pru-gcc to be installed.
* Remove linker scripts. Instead set memory sizes from specs.
* Activate --gc-sections linker option by default.
* The "--host=pru" configure option must be used instead of "--target=pru.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
The spec file was missing replacing various libs like libc, libm, etc
with their nano equiv when CT_NEWLIB_NANO_INSTALL_IN_TARGET=y. Update
the nano.spec file that is generated to rename libc, libm, etc if
CT_NEWLIB_NANO_INSTALL_IN_TARGET=y
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Issue #1535
GCC 10 changed the default to -fno-common, which leads to a linking error in GLibc older than 2.30.
This change adds -fcommon cflag for the target GLibc versions <=2.29 and GCC >=10.
This change also adds additional cflags for the target GLibc to disable
new GCC11 checks that lead to compilation errors.
Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
Explicitly passing --disable-tm-clone-registry causes gcc to create a
crtbegin.o with a zero-sized .init_array/.fini_array. This in turn
causes ld to complain.
Make CC_GCC_TM_CLONE_REGISTRY a tristate so if it's not explicitly
enabled we can let ./configure decide.
Fixes#1531
Fixes: 1e21a302 ("gcc: Add CT_CC_GCC_TM_CLONE_REGISTRY config")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This commit adds a new gcc config `CT_CC_GCC_TM_CLONE_REGISTRY` that
enables the GCC transactional memory clone registry feature for libgcc.
Note that the gcc option to control this feature is only available in
gcc 10 and above.
(see gcc commit 5a4602805eb3ebddbc935b102481e63bffc7c5e6)
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds a new config that can be used to specify the target
CXXFLAGS specific to the libstdc++ newlib-nano variant.
By default, this config is set to specify the `-fno-exceptions` option,
which disables C++ exception handling support and greatly reduces the
compiled binary size.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds two additional arguments (`cxxflags_for_target` and
`extra_cxxflags_for_target`) for the gcc backend build function that
can be used to specify custom target CXXFLAGS.
By default, the target CXXFLAGS is set to the target CFLAGS. When
`cxxflags_for_target` is specified however, it overrides that behaviour
and allows setting different target CXXFLAGS from the target CFLAGS.
The `extra_cxxflags_for_target` argument can be used to specify the
extra target CXXFLAGS to be appended to the target CXXFLAGS. This is
useful when it is necessary to append CXX-specific flags to the
existing CFLAGS to be used as the target CXXFLAGS.
A useful application of this is building full and nano versions of
libstdc++ with different target CXXFLAGS as necessitated by
`nano.specs`.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The gcc target libraries (e.g. libstdc++) are currently built without
any optimisation flag when `CT_CC_GCC_ENABLE_TARGET_OPTSPACE` is not
enabled and default to `-O0` unless user explicitly specifies an
optimisation flag.
This commit updates the gcc build script to assume `-O2` for building
target libraries unless user provides a different optimisation flag.
Note also that this is the default behaviour for gcc when
C[XX]FLAGS_FOR_TARGET is not overridden.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
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>
