Re: libtool support for LLVM's LLD linker
Bob Friesenhahn <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.general |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 21 Mar 2017, Ed Maste wrote: > On 9 January 2017 at 19:17, Ed Maste <[email protected]> wrote: >> I am (with a few others) trying to build all of the applications in >> the FreeBSD ports tree using LLVM's LLD as the linker. > > We've been making great progress linking software in the FreeBSD ports > tree with LLVM's LLD. Unfortunately, libtool is currently the largest > portability problem we're facing (in the context of LLD), and this now > applicable to LLD on at least other BSDs and Linux. > > There's a proposal[1] to have LLD include "compatible with the GNU > linkers" in its version info so that libtool treats it like GNU ld / > gold. Going down this user-agent-alike path in toolchain components is > rather unfortunate, and I'd really like it if it can be avoided (at > least in the long term) by having libtool itself treat LLD as GNU ld. > For more information see the mailing list thread[2] that prompted this > patch. What bad things happen if libtool does not decide that the linker is GNU ld? Does the situation improve if --with-gnu-ld is supplied as an argument to configure? If this causes things to work, then it is a way for the ports system to cure the problem at configure-time. Regardless of what happens with libtool in the long term, the situation for LLVM's LLD will be much better if it pretends to be GNU ld since it takes years to deploy a new libtool release across OS distributions. Clang pretends to be GCC in many ways. Bob -- Bob Friesenhahn [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool