Hi,
The problem below resulted in failures of some PowerPC sample
toolchains in crosstool-ng.
As far as I understand, the code in ld/emulparams/elf32ppccommon.sh
attempts to use /lib32 or /lib64 if the endianness of the selected
emulation matches the endianness of the machine, and use the
directories with explicit endianness (such as /lib32le, /lib32be,
/lib64le, /lib64be) otherwise. However, there are two issues with that
code:
First, it checks for *host's* triplet, not target. The host may not be
using 'le' suffix to designate its endianness - for example, it may be
little-endian by default. It also doesn't seem to make much sense to
check the host for default layout - why would the expected sysroot
layout on a big-endian host differ from that on a little-endian host?
Second, the check itself is flawed: it should be checking just the CPU
part of the triplet, not the whole string. In its current form, the
check compares $host against "*le-*" pattern - which matches
"x86_64-apple-darwin16.0".
This results in ld configured for powerpc64le-unknown-linux target on
x86_64-unknown-linux host behaving as follows:
- without -m, or with -melf64lppc it searches /lib64le first
- with '-melf64ppc' it searches /lib64 first - which seems to run
counter to the intended purpose of that code, as the target is
configured as little-endian!
'ld' works ok with libraries in /lib (which is always searched as the
last fallback, regardless of the host and selected emulation). Once
the libraries are placed in /lib64 (default gcc's directory for this
target), ld fails to find them.
This erroneous code first appeared in binutils 2.24.
Patch attached.
Regards,
Alexey.