On Monday 17 August 2009 08:00:53 Wolfgang Denk wrote:
--- a/config.mk +++ b/config.mk @@ -166,11 +166,21 @@ endif +# Special flags for CPP when processing the linker script +# Linker versions prior to 2.16 don't understand the builting +# functions SORT_BY_ALIGNMENT() and SORT_BY_NAME(), so disable these +ifeq ($(shell $(LD) -v | \
- sed -ne 's/GNU ld version ([0-9][0-9]*).([0-9][0-9]*) .*/[ \1 -lt 2
] || [ \2 -lt 16 ] && echo old_ld/p' | \ + sh),old_ld) +LDPPFLAGS += -D'SORT_BY_ALIGNMENT(x)=x' -D'SORT_BY_NAME(x)=x' +endif
now that it's in the tree, i took a closer look ... guess i should have earlier, but oh well
this check will fail with binutils 3.0+ because of the minor check for 16 without a corresponding major check.
rather than making it specific to the sort problem, why not generalize it. extract the major and minor versions and export them to the preprocessor of the linker script. then the linker script input can use these to handle macroing away the SORT_xxx stuff. if there's concern about duplicating these macros, then we can start an asm-generic/u-boot.lds.h for people to include and centralize the logic. and next time there is backwards-compatibility issues, it's trivial to support since we have the support structure in place.
the way it's written now causes ld to get executed every time config.mk is included. my current test shows that is like 80 times, or 79 useless runs. even if we make this a bit smarter (saving the output in a var and exporting it), that cuts things down to like 60 executions. considering this test is only used by the linker script code, why not keep it in the top-level Makefile.
stderr is not redirected which means if the linker outputs something to that, it can quickly cause a lot of excess noise. -mike