Introduce target-specific LDFLAGS, the same way we have CFLAGS for the target.
It seems to be helping gcc somewhat into telling the correct endianness to ld that sticks with little endian even when the target is big (eg armeb-unknown-linux-uclibcgnueabi).
There's still work to do, especially finish the gcc part that is not in this commit.
/trunk/scripts/functions | 9 7 2 0 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
1 # http://in3www.epfl.ch/~schaffne/linux-2.4-bsd-expr.patch
2 The following makes it possible to compile linux 2.4.19 to 2.4.25 on Mac OS X,
3 where "expr" doesn't understand the "length" construct
4 (which it doesn't have to, according to SuSv3
5 (see http://www.opengroup.org/onlinepubs/007904975/utilities/expr.html)
6 See also http://sources.redhat.com/ml/crossgcc/2004-02/msg00131.html
10 KERNELRELEASE "2.4.21" exceeds 64 characters
11 make: *** [include/linux/version.h] Error 1
14 diff -ur linux-2.4.23-old/Makefile linux-2.4.23/Makefile
15 --- linux-2.4.23-old/Makefile 2003-12-09 14:27:56.000000000 +0100
16 +++ linux-2.4.23/Makefile 2003-12-09 14:28:37.000000000 +0100
20 include/linux/version.h: ./Makefile
21 - @expr length "$(KERNELRELEASE)" \<= $(uts_len) > /dev/null || \
22 + @expr "$(KERNELRELEASE)" : '.*' \<= $(uts_len) > /dev/null || \
23 (echo KERNELRELEASE \"$(KERNELRELEASE)\" exceeds $(uts_len) characters >&2; false)
24 @echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver
25 @echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver