HEADS-UP: obsolete GNU as 2.17.50 retirement for FreeBSD 13, expected 2020-05-31

All architectures supported by FreeBSD now using Clang and lld, and
tools from obsolete GNU binutils 2.17.50 have been retired one by one
- most recently objdump, in r360698. There is one binutil tool left:
GNU as. I plan to disable it at the end of the month, and then remove
all of binutils some weeks later if no additional issues are found.

We have two src.conf build knobs for as - WITH_BINUTILS, which
determines whether /usr/bin/as exists in the built system, and
WITH_BINUTILS_BOOTSTRAP, which controls whether as is built as a
bootstrap tool to build the rest of the system.

1. WITH_BINUTILS (default on i386 and amd64)

Turning this off means the installed system will not have /usr/bin/as.
A ports exp-run without as is in PR 205250. On i386 the most recent
run failed in:

comms/libfec
comms/syncterm
devel/plan9port
emulators/vmw
games/dxx-rebirth
graphics/vulkan-loader
lang/hla
lang/mit-scheme
lang/ocaml
lang/ocaml-nox11
math/ldouble
multimedia/mencoder
multimedia/mplayer

amd64 has similar failures in an earlier run.

There are generally two ways to address a ports need for an assembler:

a) Add a dependency on devel/binutils to the port's Makefile:
BUILD_DEPENDS+=as:devel/binutils

b) Use Clang's integrated assembler, via the compiler driver (cc).
This is what we do for all but one file in the base system.

Option (b) is the nicer choice, as it doesn't introduce a new
dependency, but takes some more work. Option (a) is straightforward,
and I have a proposed initial set of patches at
https://reviews.freebsd.org/D24739.

My hope is that individual maintainers of affected ports can prepare
their port for the upcoming as retirement in whichever way they find
most suitable; I'll have BUILD_DEPENDS patches ready for whichever
ones are not ready at the end of the month.

2. WITH_BINUTILS_BOOTSTRAP

GNU as is built only on amd64, and is used to assemble one file, the
optimized assembly version of the Skein cryptographic hash -
skein_block_asm.s. Unfortunately it makes extensive use of macro
features that are not yet supported by Clang's integrated assembler.
There are some proposed methods of addressing (for example, committing
an assembled .o, or translating the assembly into something that IAS
can handle) but none of them are particularly palatable. Right now I
expect the most likely path forward is that we revert to the somewhat
slower C-language skein implementation.

Please let me know if you have any questions or concerns; I'm happy to
help maintainers of affected ports find and test a solution.