ld-elf2flt: behave properly when called with a name different from TARGET_ALIAS
ld-elf2flt currently handles two cases:
1 It is called as the wrapper for <TARGET_ALIAS>-ld, generally
installed in the bin/ directory of a toolchain.
2 It is called as the wrapper for "ld", generally installed in the
TARGET_ALIAS/bin/ directory of a toolchain.
Unfortunately, if for some reason it gets called using a FOOBAR-ld
name that is different from <TARGET_ALIAS>-ld, it assumes it is in
case (2), while it really is in case (1). Due to this, the path
mangling logic doesn't work, and it doesn't find ld.real.
This happens for example when the binary program in bin/ is named
arm-buildroot-uclinux-uclibcgnueabi-ld, but also has a simpler symlink
named arm-linux-ld. In this case,
arm-buildroot-uclinux-uclibcgnueabi-ld is recognized by ld-elf2flt as
containing TARGET_ALIAS, and therefore the proper logic to find
ld.real is applied. However, when arm-linux-ld is used, ld-elf2flt
doesn't find TARGET_ALIAS, and therefore assumes we're being called as
TARGET_ALIAS/bin/ld.. and searches for a program called ld.real in
bin/, which doesn't exist.
See:
$ ./output/host/bin/arm-buildroot-uclinux-uclibcgnueabi-ld
/home/thomas/buildroot/buildroot/output/host/bin/../arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files
$ ./output/host/bin/arm-linux-ld
arm-linux-ld (ld-elf2flt): error trying to exec '/home/thomas/buildroot/buildroot/output/host/bin/ld.real': execvp: No such file or directory
$ ./output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld
/home/thomas/buildroot/buildroot/output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files
This commit fixes that by inverting the logic: if we're being called
as just "ld", then we assume it's the program in
TARGET_ALIAS/bin/. Otherwise, we're called through some variant of
TARGET-ld.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>