Build toolchain components as dynamically linked executables by default

[dim]

Summary

Historically, we have built toolchain components such as cc, ld, etc as
statically linked executables. One of the reasons being that you could
sometimes save yourself from botched upgrades, by e.g. recompiling a
"known good" libc and reinstalling it.

In this day and age, we have boot environments, virtual machine
snapshots, cloud backups, and other much more reliable methods to
restore systems to working order. So I think the time is ripe to flip
this default, and link the toolchain components dynamically, just like
almost all other executables on FreeBSD.

Maybe at some point they can even become PIE executables by default! :)

[val_packett.cool]

Maybe at some point they can even become PIE executables by default! :)

What's holding this up btw? Is there any actual reason why we have any non-PIE executables at all on aarch64 and amd64?

[dim]

In D22061#482304, @greg_unrelenting.technology wrote:

Maybe at some point they can even become PIE executables by default! :)

What's holding this up btw? Is there any actual reason why we have any non-PIE executables at all on aarch64 and amd64?

The MK_PIE knob was added in a "default NO" state in rS344179 by @emaste on 2019-02-15, so it has been in there for a while. Probably nobody ran extensive tests yet with it enabled? The commit itself also has a few remarks on why certain executables do not yet have PIE enabled. I also remember there were some people posting issues with PIE and ASLR on the mailing lists, which may have been solved by now.

[jilles]

Historically, another reason was performance. For example, https://svnweb.freebsd.org/base?view=revision&revision=76801 which changed make(1) to be statically linked states performance as the reason.

Since the performance gain of static linking is in exec, exit, fork and calls across library boundaries, I imagine the gain is limited for a compiler or linker that uses considerable CPU time by itself but for things like make installworld a static make might be significantly faster.