Switch the cloudabi-toolchain port over to llvm-devel.

[ed]

Summary

Farnsworth: "Good news, everyone!" The latest revisions of LLVM trunk
not only have a version of LLD that creates usable binaries for x86-64
and aarch64, it also does a better job at creating Position Independent
Executables than the GNU linker.

Because PIE is going to become pretty important for some of the upcoming
projects (emulation on other OSes), I'd like to go ahead and switch the
cloudabi-toolchain port over to the latest snapshot of LLVM. My goal is
to revert back to a stable version (3.9) when available.

Switching to LLD involves patching up the Binutils ports to no longer
install the GNU linker (and remove the linker scripts that it uses). We
can then simply add a couple of extra symlinks to cloudabi-toolchain to
point to the LLD binary.

Note: this change still depends on the llvm-devel port being upgraded to
a more recent version (>=r265577). I'll wait until such a change has
happened.

Test Plan

The ports install fine, though the copy of LLD that's installed is still
a bit too old.

[emaste]

Do you need binutils at all?

[ed]

In D5874#125364, @emaste wrote:

Do you need binutils at all?

Hmmm... That's a good question. I often use the tools that are shipped with it (readelf, etc) but there is nothing provided by this package that now depends on Binutils. Let's drop the dependency, but keep the Binutils ports around.

[ed]

Don't depend on Binutils.

[emaste]

I often use the tools that are shipped with it (readelf, etc)

On FreeBSD-HEAD at least we can teach the system's ELF Tool Chain version of readelf, elfdump, objcopy etc., about CloudABI and avoid needing a separate install.

I just added ELFOSABI_CLOUDABI to upstream ELF Tool Chain: https://sourceforge.net/p/elftoolchain/code/3439/ and will bring it into HEAD in a bit. Perhaps you'd like to take a look at ELF Tool Chain and see if there are other CloudABI updates to make?

[ed]

Hi Ed,

In D5874#125390, @emaste wrote:

On FreeBSD-HEAD at least we can teach the system's ELF Tool Chain version of readelf, elfdump, objcopy etc., about CloudABI and avoid needing a separate install.

I just added ELFOSABI_CLOUDABI to upstream ELF Tool Chain: https://sourceforge.net/p/elftoolchain/code/3439/ and will bring it into HEAD in a bit. Perhaps you'd like to take a look at ELF Tool Chain and see if there are other CloudABI updates to make?

That sounds like a very good idea. I guess the only reason I was using the tools from Binutils is because the GNU versions that we ship with FreeBSD 10 don't work well:

• GNU strip(1) destroys the EI_OSABI field.
• The version that we ship is too old to do anything with aarch64 executables/object files. nm(1) just prints an error and readelf(1) doesn't know the relocation types.

I just tested the tools in HEAD and they work perfectly fine. Thanks for adding the CloudABI OSABI type. Apart from that I don't think I need any additional changes, but I'll keep an eye out.

Now what I do think is important is that the ELF tools that we have in the base system are still exposed under the names <arch>-<tool>, as I think Autoconf and some other build systems depend on this. Let's do the following:

• Set IGNORE= on the Binutils ports if the osreldate is high enough.
• Let this port add symlinks to the tools in /usr/bin/... for the same osreldate.
• To get consistent behaviour, re-add the dependencies on the Binutils ports if the osreldate is too low.

[ed]

Drop dependency on Binutils on FreeBSD 11 altogether.

On FreeBSD 11 we can use tools from the base system instead. Ideally
we'd want to put an IGNORE= in the Binutils ports if OSVERSION is high
enough, but due to the include system of these ports, that seems to be a
bit annoying to accomplish. For the OSVERSION test we need
<bsd.port.pre.mk>, which we cannot include there.

Let's make things easy for ourselves for now and just set CONFLICTS=
inside of the cloudabi-toolchain port.

[emaste]

This approach sounds reasonable to me

[brooks]

FYI, I've updated llvm-devel to an April 7th snapshot in r413161.