Fix sh4-unknown-linux-gnu sample.

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)

1 files changed, 1 insertions, 1 deletions

diff --git a/samples/sh4-unknown-linux-gnu/crosstool.config b/samples/sh4-unknown-linux-gnu/crosstool.config
index 3d588c64..ab0cc7a1 100644
--- a/samples/sh4-unknown-linux-gnu/crosstool.config
+++ b/samples/sh4-unknown-linux-gnu/crosstool.config
@@ -5,7 +5,7 @@ CT_ARCH_sh=y
 CT_ARCH_SH_SH4=y
 CT_KERNEL_linux=y
 CT_BINUTILS_PLUGINS=y
-CT_LIBC_glibc=y
+CT_CC_GCC_V_4_9_3=y
 CT_CC_LANG_CXX=y
 CT_DEBUG_gdb=y
 # CT_GDB_CROSS_PYTHON is not set