GNU libtool checks the output from invoking the linker with --version
and --help, in order to determine the linker "flavour" and the command-
ine arguments to use for various link operations (e.g. generating shared
libraries). To detect GNU ld it looks for the strings "GNU" and
"supported targets:.*elf". Since LLD is compatible with GNU ld we
include those same strings to fool libtool.
Quoting from a comment in the change:
This is somewhat ugly hack, but in reality, we had no choice other
than doing this. Considering the very long release cycle of Libtool,
it is not easy to improve it to recognize LLD as a GNU compatible
linker in a timely manner. Even if we can make it, there are still a
lot of "configure" scripts out there that are generated by old
version of Libtool. We cannot convince every software developer to
migrate to the latest version and re-generate scripts. So we have
this hack.
Upstream LLVM revisions r298532, r298568, r298591
Obtained from: LLVM
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The change was made to support glibc and believed to be a no-op on
FreeBSD, but that is not the case for architectures with multiple page
sizes, such as arm64. The relro p_memsz header was rounded up to the
default maximum page size (64K). When 4K pages are in use, multiple
pages beyond the final PT_LOAD segment had their permissions changed to
read-only after application of relocations and copy relocations, which
led to a segfault in certain cases.
This reverts upstream r290986. I have started a discussion about the
upstream fix on the LLVM mailing list.
Reported by: andrew
Sponsored by: The FreeBSD Foundation
