The gold linker cannot currently be built in a static toolchain build.
This may get fixed in a future version of crosstool-NG.
Also, there is a bit of weirdness here. versions of binutils >= 2.21
have GOLD (BINUTILS_HAS_GOLD), but that doesn't mean it should be used.
For instance, if the architecture is not supported.
So with that, we create a new hidden option: BINUTILS_GOLD_SUPPORT
Which in turn depends on BINUTILS_GOLD_SUPPORTS_ARCH, BINUTILS_HAS_GOLD,
and not STATIC_TOOLCHAIN... then replace anything that previously
depended on BINUTILS_HAS_GOLD with our new BINUTILS_GOLD_SUPPORT option.
This closes#210
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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.
- New configurations:
- CC_GCC_TARGET_FINAL:
Use the default targets "all" and "install" for the final compiler for
bare metal.
- Adding parameter "build_step" to function do_gcc_core_backend:
do_gcc_core_backend is used for the core compiler and in case of bare metal
for the final compiler, too. To have better control over the parameters for
the final compiler "build_step" is used.
- Used for proper logging.
- Use CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY or CT_CC_GCC_EXTRA_CONFIG_ARRAY.
- If CT_CC_GCC_TARGET_FINAL is set and the final compiler is build then the
make targets for the final compiler are used ("all", "install").
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
I forgot that the logs must stay small, and if they fail we'll grab the
last few hundered lines.
Note, the logs must stay smaller then 4M.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit introduces a configure time option to let the build know
that this is going to be an automated build.
This forces the build to disable the progress bar, log tool warnings,
and force the log level to debug.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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>
