diff options
author | Alexey Neyman <stilor@att.net> | 2015-09-30 16:31:27 -0700 |
---|---|---|
committer | Alexey Neyman <stilor@att.net> | 2015-10-15 17:34:49 -0700 |
commit | 52203df900d210b4c3d8741c5e1f61995e8bcc90 (patch) | |
tree | 51d37861d05238f5a2614e07bb5c492c21e92ba8 /patches/gcc | |
parent | 8c5de9dcd527731ced700f4f7c496e04df74c9c0 (diff) | |
download | crosstool-ng-52203df900d210b4c3d8741c5e1f61995e8bcc90.tar.gz crosstool-ng-52203df900d210b4c3d8741c5e1f61995e8bcc90.tar.bz2 crosstool-ng-52203df900d210b4c3d8741c5e1f61995e8bcc90.zip |
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)
Diffstat (limited to 'patches/gcc')
0 files changed, 0 insertions, 0 deletions