lld status on the freebsd ports

[Ed Maste via llvm-commits]

On 12 December 2016 at 12:28, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
> For the last week or so I did a push to build the freebsd ports with lld
> and see how mature lld was.

I've also started my own Poudriere builds with lld installed as
/usr/bin/ld to investigate. This is on a small, relatively slow server
at home that's not particularly speedy, and I've been aborting and
restarting the build after committing workarounds for issues.

I currently have the following changes in my ports tree:

1. fix pkg basename/dirname configure test

pkg built and was trying to link an object file containing a
version-extended symbol (basename at FBSD_1.0). I submitted
http://llvm.org/pr31495 since GNU ld handles this case, although here
it's really a bug in pkg's configure script which is now fixed in
https://github.com/freebsd/pkg/commit/05ce724323422f728b6a8c024e9822aec8bb2732

2. disable DTRACE options by default in a number of ports

It appears FreeBSD dtrace is producing objects with an incorrect
relocation that GNU ld happens to accept in some undefined way. Mark
Johnston is looking into this and for now I've just disabled the use
of userland dtrace in 9 ports.

3. use the standard -L path flag instead of -Y in graphics/libGL

-Y has slightly different behaviour (paths are appended to the default
search path list). The GNU ld man page claims it's for Solaris
compatibility, and in general I think correctly ordering -L arguments
removes any need for -Y. Change in review at
https://reviews.freebsd.org/D9022.

My patched ports tree is at
https://github.com/emaste/freebsd-ports/commits/ports-lld. I haven't
yet patched lld with the "not GNU" hack or search paths, and haven't
touched libtool in this tree. My build is still running, with a total
of 13020 ports built across multiple runs.

So far the port failures with the largest number of transitive dependencies are:

multimedia/gstreamer-plugins (947)
devel/pear (475)
audio/openal-soft (149)
lang/fpc (107)
lang/gcc6-aux (52)
lang/mono (49)

I haven't investigated these in depth, but gstreamer-plugins appears
to be due to the libtool issue. fpc reports "error: invalid alignment
of section headers" and I'll grab a reproducer cpio for it some time
after this run finishes. gcc6-aux is due to the default search paths
(the port contains a bootstrap GCC which does not pass paths via -L).