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>
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 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>
1. On SuperH, configuring GCC with explicit variant of the CPU
(like "sh4") limits the default set of multilibs to just that CPU
and requires --with-multilib-list to change. Allow for "unspecified"
variant, so that we can defer to GCC to determine the list.
2. Support toolchains with both endiannesses at the same time.
3. Add a SuperH/newlib sample
4. Add more flags processing for uClibc
Signed-off-by: Alexey Neyman <stilor@att.net>
It fails to compile with the only locale version available (030818)
(on master too, with exactly the same error).
uClibc-ng does not use pregenerated locales.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Need GDB8.0 milestone
- Make uClibc "master" package
- Rename bionic -> android-ndk to match the package name and
support suffixes for archives
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>
instead of 'make oldconfig' and responding 'y'. This avoids 'Broken pipe'
errors in the log, as well as selects default setting for all options not
explicitly set.
This requires a small fix in the old uClibc. Won't have to maintain that fix
for long though :)
Signed-off-by: Alexey Neyman <stilor@att.net>
So that uClibc config can be matched to Buildroot's expectations via
the menu, without the need for a saved config.
Signed-off-by: Alexey Neyman <stilor@att.net>
In that case, CT_GetCustom just creates a symlink to the original.
In that case, 'cp -a <path> .' gives an error and 'cp -a <path> <newdir>'
creates <newdir> as a symlink (which will then run the build inside
the shared directory, .build/src/<package>).
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>
1.0.15 only kept a single LINUXTHREADS option, and renamed it, making it
no longer option-compatible with uClibc.
The option for "1.0.14 or later" version of uClibc-ng is not currently
used; rename it to "1.0.15 or later" and use it to handle newer
uClibc-ng's linuxthreads.
m68k happens to be the only sample using linuxthreads.
Signed-off-by: Alexey Neyman <stilor@att.net>
This change adds native ldd and ldconfig utils to sysroot.
For glibc just 'make install' installs everything including utils.
For uclibc there exists a separate goal 'install_utils'. Make it.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
It turns out that core GCC on binfmt architectures (m68k, for example)
cannot produce the final executable (looks for ld.real in the wrong
place). Need to wait for the final gcc to become available.
Signed-off-by: Alexey Neyman <stilor@att.net>
'ld' does not search for dependency libraries in multi_os_directory, so
if there's both multi_os_directory and multi_root, and there is only one
configuration in each multi_root, forgo the multi_os_directory suffix.
Needed for sh4-multilib-linux-uclibc.
Signed-off-by: Alexey Neyman <stilor@att.net>
Create a separate 'libc_backend_once', install headers into a
subdirectory (different sets of headers are installed for 32- and 64-bit
architectures), and create a symlink for the dynamic linker location
expected by GCC.
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>
In preparation for multilib support, use the same "backend" model that
is already employed by glibc and musl.
Also, the verbosity setting descriptions were swapped. V=2 is actually
less verbose than V=1: V=1 prints full commands, while V=2 prints 'CC
<file> <defines>'.
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 updates the build scripts to match the new usage of
CT_GetCustom from the previous change.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per the change notes of GCC-6:
https://gcc.gnu.org/gcc-6/changes.html
and conversations I've had with the buildroot folks, there is no need
to support sh5/sh64.
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>
I've added the .config files to contrib/uClibc-defconfigs from buildroot
to use as default configs if they are not provided in the sample.
If a particular architecture really needs an option set, it should be
either updated in the manange_uClibc_config function in
scripts/build/libc/uClibc.sh or a custom ${uclibc_name}.config should be
added to the sample (usually via `ct-ng saveconfig`).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates uClibc to use the new CT_Kconfig options from the
previous commit. The older sed method of sanity checking the uClibc
.config was error prone and clumsy.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit removes blackfin support.
I'm open to re-adding blackfin after crosstool-1.23.0 is released, but
it is currently too difficult to port forward to newer versions of gcc
and uclibc.
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>
Support for fenv.h is a little bit more tricky that enabling it only
for x86-32 is not right.
Add an option for the user to choose whther to install fenv.h or not.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
