This enables the resulting toolchaing to be used to build a canadian
cross to x86_64-pc-linux-gnu target. Unmark that sample as broken,
it now builds successfully.
It is likely that it is affected by issue #483, too - I see the
resulting gcc executable has a DLL dependency on libiconv-2.dll,
which is only installed into .build/.../buildtools. This will be
investigated/fixed separately.
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>
Current build passes {CFLAGS,LDFLAGS}_FOR_HOST - which breaks canadian cross
(e.g. tried building for x86_64-unknown-linux-uclibc host). This dates
back to the days of yore when CFLAGS were set directly in the do_gcc_core_backend
(and that function is used as the final gcc's backend).
do_gcc_core_backend is now passed with CFLAGS/LDFLAGS to use, so let
the pass-1/pass-2/final-for-build steps pass the appropriate flags.
Signed-off-by: Alexey Neyman <stilor@att.net>
Put xtensa core name to the tuple vendor string (without any overlay the
default core is 'fsf') and rename sample directory accordingly.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
This fixes build for elf target with windowed xtensa core that currently
breaks with the following error message:
unwind-dw2-fde-dip.c:36:40: fatal error: elf.h: No such file or directory
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Add -mlongcalls and -mtext-section-literals to target CFLAGS. Target
libraries built with these flags have great call range, useful for linux
applications.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
This fixes toolchain build with --text-section-literals, which should
normally be enabled for linux targets.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
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>
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>
Commit 6f8e89cb5c broke that option.
Since ${make} points to /usr/bin/make, making the symlink from gmake
to /usr/bin/make is obviously the wrong decision. gmake should link to
our (old-versioned) self-built make.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
GLIBC 2.24 declared readdir_r as deprecated and suggests to use readdir.
uClibc-ng's readdir is thread-safe as well.
Signed-off-by: Alexey Neyman <stilor@att.net>
The patch provided by the original submitter did not apply cleanly to 4.9.3; had a fuzz 2.
We only allow fuzz 1. Fix up the patch.
Signed-off-by: Alexey Neyman <stilor@att.net>
1. Check if anything was installed outside sysroot; on some [baremetal only?]
configurations GCC doesn't install anything to ${CT_PREFIX_DIR}/${CT_TARGET}/lib.
2. We need to create <sysroot>/lib/<multilib> if it doesn't exist
(MUSL only installs in <sysroot>/usr/lib).
3. Do not move the linker scripts; elf2flt expects to find them
in gcc's dir, not sysroot.
Signed-off-by: Alexey Neyman <stilor@att.net>
