buildsys: order lib/ehframe-term.o after the generated headers
A parallel build fails on arm:
CC lib/ehframe-term.o
In file included from ./include/libc-symbols.h:49,
from <command-line>:
./libc/sysdeps/linux/arm/bits/uClibc_arch_features.h:73:11: fatal error:
bits/uClibc_config.h: No such file or directory
Nothing orders that compile after the header generation. "all" has pregen,
libs and startfiles as three prerequisites, and make builds the
prerequisites of a target in parallel -- "libs: pregen" does not put pregen
before the objects libs also depends on. Every object built straight into
lib/ therefore says so itself, and the line right below this one does it for
the startfiles:
$(CRTS) $(CTOR_TARGETS) $(CRTS_COMPAT) $(CRTRELOC): | headers
0a688ba5b ("buildsys: terminate .eh_frame in shared objects") added a second
such object without that edge.
arm is the only architecture that notices: its bits/uClibc_arch_features.h
includes the generated bits/uClibc_config.h to check __CONFIG_ARM_EABI__
against the compiler's __ARM_EABI__. Elsewhere the file compiles without it
and the missing edge stays invisible. It also stays invisible wherever an
earlier install left a bits/uClibc_config.h in the include path; a toolchain
sysroot that is being rebuilt has none, which is why this appears when the
toolchain and the library are built together.
Order-only, like the startfiles line above: the header is regenerated on
every configuration change, and a normal prerequisite would recompile the
object each time for nothing.
Reported-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Ramin Moussavi <lordrasmus@gmail.com>