GCC does not distinguish the resulting binary by the CFLAGS (e.g. based
on which -march= was given). This means, while it will use the right
libraries for linking, at runtime they are all going to request the same
ld.so path and load the libraries from the same default path.
Signed-off-by: Alexey Neyman <stilor@att.net>
Hence, it is better to enforce via config rules: elf2flt does not
play nice with ld wrapper, when both ld.bfd and ld.gold are present.
Limit the choices to just 'ld.bfd' for flat-format architectures.
Signed-off-by: Alexey Neyman <stilor@att.net>
... that exhibited the issue with elf2flt configuration. Original reported
did not provide the config, and did not respond.
Signed-off-by: Alexey Neyman <stilor@att.net>
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>
So that 'ct-ng saveconfig' works properly.
Also, run it through 'ct-ng saveconfig' so that default options are removed.
Signed-off-by: Alexey Neyman <stilor@att.net>
This follows the trend set by 1*.sh scripts that configure ISL, GMP,
MPFR, CLooG, etc. Building with shared libraries presents all kinds
of problems:
- The shared libraries need to be installed into ${CT_PREFIX_DIR}.
- The binaries linked against companion libs need to have proper
RPATH, or they're looking for shared libs in
.build/${CT_PREFIX}/buildtools/lib.
- All libraries must agree as to whether they're built shared,
static, or both. Otherwise, gettext tries to link in static libncurses.a
into a shared library and fails (since libncurses was compiled without
the -fPIC switch and hence contains relocations that cannot be handled
in a shared library).
So this fixes the current mess. If we decide to re-enable building
the companion libs shared, we should probably make this dependent on
a separate suboption of CT_STATIC_TOOLCHAIN.
Add a config loosely based on one reported in the issue 274.
Signed-off-by: Alexey Neyman <stilor@att.net>
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>
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>
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>
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>
No threads (uclibc/libpthread does not compile on ARMv8); no C++ (libitm
depends on pthreads), no GDB/DUMA (depend on threads).
Signed-off-by: Alexey Neyman <stilor@att.net>
Based on the following samples:
- x86_64-unknown-linux-gnu (-m64/-m32/-mx32)
- powerpc64-unknown-linux-gnu (-m64/-m32)
- mipsel-unknown-linux-gnu (-mabi={32,n32,64})
- sh4-unknown-linux-gnu (-m4/-m4a)
- x86_64-unknown-linux-uclibc (-m64/-m32)
- mips64el-unknown-linux-uclibc (-mabi={32,n32,64})
New samples:
- sparc64-multilib-linux-gnu (-m64/-m32)
- sh4-multilib-linux-uclibc (-m4/-m4a/-m3)
- x86_64-multilib-linux-musl (-m64/-m32)
Notably missing is arm-unknown-linux-gnu (aprofile): GLIBC does not
compile in one of the variants in its multilib set (-march=armv4t
-mthumb) due to missing atomic ops implementation.
Signed-off-by: Alexey Neyman <stilor@att.net>
This change adds a powerpc64le-unknown-linux-gnu sample that can be used
to quickly create a little-endian tool-chain for powerpc64
architecture. This sample is based on the earlier work done by "Yann
E. MORIN" to add support for powerpc64 tool chain and implementing the
power64-unknown-linux-gnu sample. The existing sample however generates
a big-endian tool chain by default.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
With avr-libc 2.0.0 released, we no longer need to force gcc 4.9.x for
the avr toolchain. So, remove the gcc version constraint and allow it to
follow the default gcc version. There is also no need to force companion
libraries' versions anymore.
The 'experimental' flag was also removed from the description as it
seems to be following upstream development now.
This sample has been build tested on Arch Linux and Ubuntu 14.04 hosts.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
I couldn't get this sample to build. I tried rolling ct-ng back to 1.22
and back to the commit that introduced it, to no avail. Not sure if it
ever built on my machine.
The first problem is the failure to build binutils/gold because of the
missing <pthread.h> in mingw. However, even if CT_BINUTILS_GOLD_THREADS
option is unset, the build dies in configure of the pass-1 of the core CC.
The config.log states that it failed to link with libmpfr.a, which has
a lot of undefined references to symbols like '__imp___iob_func'.
Googling shows that these symbols are some dark Cygwin/MinGW magic and I
do not have the knowledge of these arcana. Let some other MinGWizard fix
it another day.
Signed-off-by: Alexey Neyman <stilor@att.net>
There is invalid assembly in dmalloc for PowerPC. The issue is that
'stw' expects a memory operand, and =g constraint allows both registers
and memory. Newer GCC tends to choose register even at -O0, resulting in
invalid assembly. Instead, force a register constraint in 'mflr' and let
GCC decide if it wants to store it into memory at all.
Reported this upstream.
Signed-off-by: Alexey Neyman <stilor@att.net>
With the upcoming release of 1.22.0, mingw-w64 is still in an
experimental state, and is not considered to be fully supported yet.
This change should be reverted after the release.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per 4be766254d, mips64 is not longer
experimental, and as such, the samples should not need it enabled.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Drop ARCH_ARCH/ARCH_TUNE where it is overridden by ARCH_CPU. Also, same
updates as in the previous batch for architectures with
!ARCH_EXCLUSIVE_WITH_CPU (i.e. where there is no need to drop
ARCH_CPU/ARCH_TUNE).
Signed-off-by: Alexey Neyman <stilor@att.net>
I was going to start doing some autoconf work, and noticed that
configure.in was executable. Then I noticed Makefile.in was executable.
o.O
So, I ran ```find . -type f -executable``` and found a bunch of files
that shouldn't be set executable.
This commit makes them normal files again.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit removes per-sample configuration files for uClibc and falls
back to using the default config file in contrib/uClibc-defconfigs.
Only one sample is broken:
* powerpc-unknown-linux-uclibc
* breaks on dmalloc
I will come back and work on the dmalloc failure later, but I don't want it to
hold up getting uClibc-ng out in ct-ng.
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 change, as per #222, reduces the number of supported releases of
gcc to the latest branch releases.
I noticed while doing this work that gcc-4.5.4 was never added, so I
moved patches for gcc-4.5.3 to 4.5.4 and updated the
bfin-unknown-linux-uclibc example. Also, 120-siginfo.patch was fixed
upstream in the 4.5.4 release, so this patch is omitted.
I also bumped the avr sample to 4.9.3 from 4.9.2.
With the addition of gcc-5.x, the gcc release team now releases the
major.minor.0 versions, while updates to the branch are available in
svn/git. We'll address that when we get to issue #219. This change just
removes CC_GCC_5_1 and moves CC_GCC_5_2 to CC_GCC_5, and removes
CC_GCC_5_1_or_later and moves CC_GCC_5_2_or_later to CC_GCC_5_or_later.
This is the first of two part changes, as mentioned in #222.
This change is slated for release in 1.22.0. The next change will be
slated for 1.23.0, and will limit gcc versions to what is on
https://gcc.gnu.org under "Release Series and Status", which is
currently 4.9.3 and 5.2.0, although I will also support the previous
supported version. In this example that would be 4.8.5.
Last, but not least, this change also retires AVR32 support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Some older versions of configure (including the one in GMP 4.3.2)
interpret the $ECHO environment variable as the `echo' utility to
use. CT-NG sets the variable to `:' and exports it if V=0 or V=1
is supplied, breaking the samples using such configure. This currently
includes bfin-unknown-linux-uclibc and powerpc-unknown-linux-uclibc.
Also, correct the description of the V= variable - V=0 is *not* the
default; in fact, default does not correspond to any of the V=[012]
values.
Signed-off-by: Alexey Neyman <stilor@att.net>
Instead, continue until the end and provide a summary (PASS/XFAIL/FAIL)
at the end. If there are any FAILs, exit with code 1.
Signed-off-by: Alexey Neyman <stilor@att.net>
First, build cross samples (indicated by lack of comma in their names);
then, build canadian cross samples (and, when they are supported,
cross-native). While building canadian cross, set up the path to the
build-to-host cross if it was built previously.
Signed-off-by: Alexey Neyman <stilor@att.net>
'make oldconfig' results in asking the user about options not explicitly
set in the defconfig. Instead of copying, run 'conf --defconfig', as in
the normal sample's build sequence. Also, invoke 'conf --oldconfig'
directly, with a -s option, to avoid spamming with useless
"configuration written to .config" messages.
Signed-off-by: Alexey Neyman <stilor@att.net>
With current name, 'make saveconfig' is broken for this sample. Also, it
is confusing to have a sample named 'nios2-elf-mingw32' while show-tuple
refers to it as 'nios2-spico-elf' and saveconfig attempts to save it
into 'i686-w64-mingw32,nios2-spico-elf'.
Signed-off-by: Alexey Neyman <stilor@att.net>
Building cross-gdb in canadian cross requires expat/ncurses for the
host. Currently, 300-gdb.sh only builds expat/ncurses for the target
(for native-gdb). For cross-gdb on regular cross (build==host), expat
and ncurses are expected to be provided by the host.
There are two approaches possible:
- If building for canadian cross, build expat/ncurses for cross-gdb
just as the native-gdb does.
- Promote expat/ncurses to first class citizens and build them as
companion libs during the build of the build-to-host toolchain.
I am leaning towards the latter approach - it would also allow to
specify the versions for expat/ncurses rather than have them hardcoded
in 300-gdb.sh - but would appreciate feedback.
Signed-off-by: Alexey Neyman <stilor@att.net>
Error message:
[EXTRA] Preparing working directories
[ERROR] Missing: 'i586-mingw32msvc-ar' or 'i586-mingw32msvc-ar' or 'ar': either needed!
Signed-off-by: Alexey Neyman <stilor@att.net>
The issue with this sample is that the sh4-* targets in GCC do not
implement __builtin_trap() function. Starting with release 5.1,
GCC inserts abort() calls where NULL pointers are dereferenced. The
elf/dl-conflict.c in glibc is one such place: it calls elf_machine_rela
with NULL `sym' pointer. This causes an undefined `abort' symbol to
appear in the object file and as a result, pulls in some files during
the linking of the dynamic loader that are not supposed to. Eventually,
it results in link error due to multiple definitions of _itoa and some
other symbols.
The right fix would be to implement __builtin_trap() for sh4 in GCC.
A workaround would be adding -fno-delete-null-pointer-checks to
CFLAGS-dl-conflict.c in elf/Makefile. Until either of these happens,
though, pin the GCC version to 4.9.3 - the last that did not generate
`abort' calls. Note that the version where GCC started to generate
`abort' calls is apparently different for different architectures;
the issue in [1] was reported against GCC 4.9.
References:
[1] https://www.sourceware.org/ml/libc-alpha/2014-10/msg00807.html
(similar issue on HP-PA which was resolved by implementing
__builtin_trap)
Options were renamed. However, matching current option names result
in a compile error for strfmon_l.o in glibc: GCC 4.6 detects an
unitialized variable in its own va_arg() implementation. Likely,
an older GLIBC was used when this sample was submitted - which did
not provide -Werror in CFLAGS.
Thus, use most recent GCC (5.2.0) and revert GLIBC_FORCE_UNWIND to
its default value, 'y' (as forced unwind is required with this version).
- Incompatible ISL/CLooG were requested by config after newer releases
of both were brought in.
- Consistency with other samples: save tarballs (which will avoid
downloading them each time from Travis), extra logging.
This should ideally be upstreamed to uclibc maintainers, but with the
last release more than 3 years ago, I wouldn't hold my breath for a
fix being released any time soon.
As of right now, ltrace fails to build. To get CI happy, lets just
disable it!
When we fix ltrace, just revert this change.
This is also in reference to bug #115
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
.. and set CT_TARGET_VENDOR to w64. Otherwise config.gcc doesn't
pickup the right files for include_next (and probably many other
things go wrong too).
w64 has been the correct vendor for absolutely ages now on all
distributions that provide MinGW-w64 cross compilers.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
C++ support is enabled in most samples existing in crosstool-ng and is also
supported by AVR.
As pointed out in pull request #124 in the crosstool-ng github, Arduino based
projects willing to use this toolchain will require C++ support.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
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.
Some patches are required in avr-libc for a toolchain with gcc 5.x to
work. These patches are still not part of any avr-libc release version,
so the config sample currently forces 4.9.x to avoid requiring to clone
avr-libc trunk.
References:
https://savannah.nongnu.org/bugs/?44574https://gcc.gnu.org/gcc-5/changes.html
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
