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>
There are some useful tools such as widl, gendef, genidl ... etc.
provided by mingw-w64 and do not waste the developers' works.
Signed-off-by: Li-Hang Lin <lihang.lin@gmail.com>
For that, make CT_BUILD_TOP_DIR a non-settable config option (so that it is
recursively expanded with CT_HOST/CT_TARGET). Use a common prefix, with
same default as for regular sample build.
Use showConfig.sh to determine host toolchain path (for canadian crosses)
and build directory to be removed.
Remove LIBC_SYSROOT_ARG (unused).
Signed-off-by: Alexey Neyman <stilor@att.net>
Makes them sorted out by host, and removes the need for similar hack in
samples.mk.
Change how canadian crosses are named: using `=' character resulted in
Glibc build failure.
Move loading config into a common function, CT_LoadConfig.
Signed-off-by: Alexey Neyman <stilor@att.net>
Also, move 'devel' to the bottom - we don't want this ever-moving tag
to be default in the released product.
Signed-off-by: Alexey Neyman <stilor@att.net>
Linaro GDB 7.2 no longer available from Linaro's website; removed.
Linaro GDB 7.5 had incorrect version (the tarball on linaro.org does
not have a -1 patch level).
Add/update latest versions on each (otherwise supported) branches of
GCC, GDB, binutils, glibc.
Signed-off-by: Alexey Neyman <stilor@att.net>
GCC accepts them using the same check for "0.15 or newer", but since
they are not "officially recommended" by GCC installation guide,
mark them as experimental.
Signed-off-by: Alexey Neyman <stilor@att.net>
Source-wise, both CLooG and GCC depend on ISL, and GCC may depend on
CLooG. However, GCC may or may not require CLooG (GCC5 dropped this
dependency). Also, all GCC4.x releases build fine with any of the CLooG
releases we have.
With all that in mind, it is easier to specify ISL dependency on
particular GCC releases; and CLooG dependency (if applicable) on ISL.
Signed-off-by: Alexey Neyman <stilor@att.net>
None of the bare metal C library choices (avr-libc, newlib) support
installing into sysroot. Nor does it make any sense, since sysroot
implies a file system, which in turn implies an OS.
Make them configurable, default to y when build!=host (i.e.
canadian or cross-native) because we don't know what libraries the host
will provide. GLIBC, as previously, selects them explicitly.
Signed-off-by: Alexey Neyman <stilor@att.net>
- No new releases in almost 10 year.
- No public bug tracker or VCS.
- No responses from maintainer over sent patches.
RIP, dmalloc.
Signed-off-by: Alexey Neyman <stilor@att.net>
This is workaround, as more packages require similar tweaks (some
depend on X_Y_Z_or_later config variables either in kconfig, or in
the build scripts.
We should have a CT_CompareVersion, that will apply the default
or per-package method of comparison.
Signed-off-by: Alexey Neyman <stilor@att.net>
In case of bare metal, newlib is built without any syscalls,
and dmalloc fails to link with undefined references to _exit,
fstat, open, sbrk and so on.
Same for DUMA: depends on <memory.h>, not available with newlib.
Signed-off-by: Alexey Neyman <stilor@att.net>
To build uClibc correctly we need correct endianness selected in the
crosstool-NG. Xtensa cores may be little- or big-endian, but this
property is static. The toolchain knows the core endianness and doesn't
need options to select it.
Enable ARCH_SUPPORTS_BOTH_ENDIAN and select LE by default. Specify empty
CT_ARCH_ENDIAN_CFLAG so that -m{big,little}-endian don't get added to
the TARGET_CFLAGS, as it's not supported by gcc. Specify empty
CT_ARCH_ENDIAN_LDFLAG so that -EB/-EL don't get added to the
TARGET_LDFLAGS as they are ignored. Select big-endian in the example
xtensa-unknown-linux-uclibc configuration.
This fixes uClibc toolchain build for little-endian cores.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Allow selection of make/m4/... version. Support imports of new versions
via addToolVersion.sh. Import newest versions of the companion tools.
One non-trivial change is the handling of make versions. Existing code
was not handling make companion tool as described (see the previous
commit). However, since most modern systems have make 4.x, that previous
commit made crosstool-ng always build make as a companion tool.
This traces back to the commit dd15c93 from 2014. That commit's log message
says that actually it was 3.81 which broke the build for certain component
(it was originally breaking eglibc, but I noticed it was breaking current
glibc on powerpc64), and introduced an option to force using 3.81 by
"components that really need it". It looks like in 2.5 years we haven't
seen any such components that really need make 3.81, and (given that make
has already had a few releases since 3.81) we're unlikely to see them
in the future.
Hence, the configure check is changed from "exactly 3.81" to "3.81 or newer".
In its current form, configure will accept make 3.80+, and will not require
make as a companion tool for 3.81+. We might want to bump the latter check
to even newer version given the claim from dd15c93. Killed
COMP_TOOLS_make_3_81_NEEDED.
Anyway, I retained 3.81 just in case; ditto for m4 1.14.3, autoconf 2.65
and automake 1.11.1.
Signed-off-by: Alexey Neyman <stilor@att.net>
1.0.18 changed the dependencies for the static libraries, notably
in libc/Makefile.in. This resulted in packing a lot of unrelated
stuff into libc.a, including (sic!) a nested .a library and stuff
from other libraries such as libdl. This results in a failure to
statically link with thus created libc.a:
.../libc.a(libdl.os):(.literal+0x74): undefined reference to `_dl_tlsdesc_return'
This was breaking xtensa-*-uclibc sample.
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>
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>
- Dump CT_LIBC_EXTRA_CC_ARGS: instead, treat CT_LIBC_EXTRA_CFLAGS as
arguments to CC (or they are not applied to .S, for example).
Combine them with multi_flags and CT_TARGET_CFLAGS in proper order.
- Analyze thus combined flags to determine --with-fp/--without-fp.
Don't need to check CT_ARCH_FLOAT - it is reflected in
CT_TARGET_CFLAGS anyway. Check more soft/hard float options defined
on different architectures.
- Drop checking for endianness flags: they are not reflected in
configure arguments in any way, and they're already present in CFLAGS
(either via multi_flags or via CT_TARGET_CFLAGS). Besides,
CT_ARCH_ENDIAN_OPT was actually called CT_ARCH_ENDIAN_CFLAG, so this
was a no-op anyway.
Signed-off-by: Alexey Neyman <stilor@att.net>
On some arches (e.g. MIPS) the options like -mabi do not work if
specified more than once (see the comment in 100-gcc.sh). Therefore,
we need to determine which of the options produced by <arch>.sh can
be passed to multilib builds and which must be removed (i.e., which
options vary among the multilibs).
This presents a chicken-and-egg problem. GCC developers, in their
infinite wisdom, do not allow arbitrary multilib specification to be
supplied to GCC's configure. Instead, the target (and sometimes some
extra options) determine the set of multilibs - which may include
different CPUs, different ABIs, different endianness, different FPUs,
different floating-point ABIs, ... That is, we don't know which parts
vary until we build GCC and ask it.
So, the solution implemented here is:
- For multilib builds, start with empty CT_ARCH_TARGET_CFLAGS/LDFLAGS.
- For multilib builds, require core pass 1. Pass 1 does not build any
target binaries, so at that point, our target options have not been
used yet.
- Provide an API to modify the environment variables for the steps that
follow the current one.
- As a part of multilib-related housekeeping, determine the variable
part of multilibs and filter out these options; pass the rest into
CT_TARGET_CFLAGS/LDFLAGS.
This still does not handle extra dependencies between GCC options (like
-ma implying -mcpu=X -mtune=Y, etc.) but I feel that would complicate
matters too much. Let's leave this until there's a compelling case for
it.
Also, query GCC's sysroot suffix for targets that use it (SuperH,
for example) - the default multilib may not work if the command line
specifies the default option explicitly (%sysroot_suffix_spec is not
aware of multilib defaults).
Signed-off-by: Alexey Neyman <stilor@att.net>
Written by Bryan Hundven.
Modified by Alexey Neyman to actually add the option to gcc.in.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
Now that libc backend installs the libraries into the directory reported
by gcc as 'multi-os-directory', sh4 libraries are installed into a '!m4'
subdirectory. This directory then confuses GNU ld, which assumes the
exclamation mark to be a word separator and attempts to link to
'/usr/lib' (a directory). However, if multilib is enabled, the default
libraries are installed into the [expected] '/usr/lib/./'. This looks
like an artifact of SuperH's unique way of specifying the multilibs to
be built in GCC (which may list exclusions, starting with '!').
Signed-off-by: Alexey Neyman <stilor@att.net>
If EXPERIMENTAL is not set, the only choice for version is the set of
released versions - currently, 1.1.14. But this only option is disabled
because it is also marked EXPERIMENTAL; this leaves no available choices
in the configuration.
Marking MUSL as experimental: it seems to have header issues which
prevent, for example, gdbserver from building. musl copied chunks of
ptrace.h code from the kernel into its own headers, which now clash with
Linux kernel headers. Manifests at least on SH4 target.
Also, musl breaks in powerpc builds: GCC balks at it with "unsupported
DEFAULT_LIBC" message. Also, 64-bit powerpc and mips are not supported.
So, until someone figures out the dependencies for musl in config/, mark
it experimental.
Signed-off-by: Alexey Neyman <stilor@att.net>
The avr-libc project has released version 2.0.0:
http://savannah.nongnu.org/forum/forum.php?forum_id=8460
Apart from changes and bugfixes, this release adds support for gcc 5,
which allows us to build gcc 5 avr toolchains and also to update our avr
sample.
avr-libc 2.0.0 has been build tested both with gcc 4.9.3 and gcc 5.3.0.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
