update SDK to v0.14.0

[bcressey]

Issue number:
N/A

Description of changes:
This release of the SDK includes Rust 1.47 and Go 1.15.4. It also changes the OS used to build the C/C++ toolchain from Fedora 32 to Ubuntu 16.04, to allow the C compiler to run on older distros.

Add -linkmode=external to ldflags for all Go packages, which preserves the behavior of using the external linker with -buildmode=pie.

Testing done:
Built for x86_64 and aarch64 on both architectures. Verified that AMIs started correctly - all services up, no unexpected errors in the journal.

Sonobuoy tests passed for aws-k8s-1.18. Note that I used the v1.17.9 conformance image for aarch64, and v1.18.8 for x86_64, since more recent conformance images do not run on aarch64.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[samuelkarp]

Add -linkmode=external to ldflags for all Go packages, which preserves the behavior of using the external linker with -buildmode=pie.

Where did you find this documented? A few minutes of Googling isn't turning anything useful up for me yet...

[bcressey]

Where did you find this documented? A few minutes of Googling isn't turning anything useful up for me yet...

It's in the Go 1.15 release notes.

The linker now defaults to internal linking mode for -buildmode=pie on linux/amd64 and linux/arm64, so these configurations no longer require a C linker. External linking mode (which was the default in Go 1.14 for -buildmode=pie) can still be requested with -ldflags=-linkmode=external flag.

[samuelkarp]

Got it. Since the internal linker can now link PIE executables, is there any particular reason you want to match Go 1.14 and use the external linker?

[bcressey]

Got it. Since the internal linker can now link PIE executables, is there any particular reason you want to match Go 1.14 and use the external linker?

Using the external linker will be needed if linking with C libraries in our sysroot; I'd prefer to always use the same path rather than sometimes one and sometimes another.

Linking with gcc also ensures that our common linker flags (-Wl,-z,relro -Wl,-z,now) are applied everywhere; if we add more flags later, we don't have to remember that Go programs do something slightly different and make the changes there as well.

[samuelkarp]

With Go 1.15 we risk containerd/containerd#4509, especially if we upgrade to containerd 1.4.0. It's probably a good idea for us to upgrade to containerd 1.4.1 or move back to Go 1.14.