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>
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>
Convert absolute targets to relative so that they are valid on the host,
too. The procedure is very similar to uclibc, so it is moved into a
common function.
Signed-off-by: Alexey Neyman <stilor@att.net>
... and in addition to final toolchain aliasing, use it when configuring
multilibs for glibc/musl. Note that uClibc does not need it, it is
explicitly selecting the tools using CROSS_PREFIX.
Signed-off-by: Alexey Neyman <stilor@att.net>
The referenced commit replaced 'make' with '${make}' everywhere. This is
wrong for at least the utilities that we may build as companion tools
(make, libtool): this will always invoke the version detected by configure
by supplying the absolute path. In other words, the wrappers in
.build/tools/bin are not fallbacks - they are either temporary (in case
a respective companion tool is built) or permanent redirectors.
This is the reason why the PATH= has .build/*/buildtools/bin at higher
precedence than .build/tools/bin; the latter has the versions detected by
configure and the former has the versions built as companion tools.
Revert the rest of the gang (grep/sed/...) for consistency. After all,
we may decide to supply some of them as well (awk, for instance).
Signed-off-by: Alexey Neyman <stilor@att.net>
This step was only used in uClibc. However, with upcoming multilib, the
config management will have to be done for each variant differently,
anyway.
uClibc was the only user of libc_check_config step, as well as
CT_CONFIG_DIR directory. Retire these.
Two other clean-ups in uClibc.sh:
- KERNEL_HEADERS check seems to be bogus, this config option is not
present even in 0.9.30 - which is not supported already.
- SHARED_LIB_LOADER_PREFIX was renamed to MULTILIB_DIR in 0.9.31,
according to ChangeLog - and MULTILIB_DIR is passed from command line
instead.
Signed-off-by: Alexey Neyman <stilor@att.net>
Install startfiles for libc variants into the most specific combination
(suffixed sysroot, if applicable + suffixed multi-os dir, if
applicable). Install headers once in every suffixed sysroot (although it
seems that GCC picks up headers from top-level sysroot, GCC manual
claims that sysroot suffix affects headers search path).
In uClibc, this requires a better sanitization of the directory: it
creates symlinks from {sysroot}/usr/lib/{multi_os_dir} to
{sysroot}/lib/{multi_os_dir} and to do so, it counts the number of path
components in the libdir. This breaks if one of such components is `..'
- symlinks contain an extra `../..' then. Since such sanitization had to
be implemented anyway, use it in other places to print more sensible
directory names.
Also, fix the description of configure --host/--target per musl's
configure help message (and its actual code).
Signed-off-by: Alexey Neyman <stilor@att.net>
This commit moves the do_libc_configure function to do_libc_backend and
switches do_libc_start_files and do_libc_final to call do_libc_backend.
The major reason for the rewrite is that musl => 1.1.13 has had it's own
build system rewritten and can now build out-of-tree.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates the build scripts to match the new usage of
CT_GetCustom from the previous change.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
We check for apps:
* make
* sed
* grep
* awk
* libtool/libtoolize
* install
* patch
* and more
...during configure. Our scripts should be consistent about using the
variables that define where the found tool was found.
Of course, we do hard-link these tools in buildtools, but that should be
a backup for the components we are building. Our scripts should always
use the tools we find.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit adds support for the avr-libc C library.
According to the project page at http://www.nongnu.org/avr-libc , the
avr-libc package provides a subset of the standard C library for Atmel
AVR 8-bit RISC microcontrollers. In addition, the library provides the
basic startup code needed by most applications.
Support for this library in crosstool-ng is only enabled for the AVR
8-bit target.
The avr-libc manual and most distributions build the AVR 8-bit gcc
toolchain with the "avr" (non-canonical) target.
Some experimentation also led to the conclusion that other (canonical)
targets are not very well supported, so we force the "avr" target for
crosstool-ng as well.
The manual also recommends building avr-libc after the final gcc build.
To accomplish this with crosstool-ng, a new do_libc_post_cc step is
added, in which currently only avr-libc performs its build, and is a
no-op for the other libc options.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
This commit adds a configuration knob for enabling extra developer
warnings to be enabled during the musl-libc build.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This option enables a configuration knob for adding debugging info.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This patch adds initial support for musl-libc.
Musl-libc versions currently supported:
* 1.0.3 (Stable)
* 1.1.3 (Previous Mainline)
* 1.1.4 (Mainline)
Futher improvements are needed.
* gcc-4.9.x has issues (Might be fixed in musl-1.1.4).
* Multilib support is needed.
* Checks to make sure paths are correct.
* Move to 2-step gcc build. 3-step build is not necessary.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: removed the gcc musl patch, to be added later;
removed dead code do_get_arch()]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
