While moving from systemd-sysv-utils to systemd w/ USE=sysv-utils I
forgot that USE=symlink-usr needed special handling to ensure the
symlinks were created correctly.
The `build_toolchains` process upgrades the @system package set rather
than @world before building the cross toolchains. This means systemd
will be upgraded, replacing systemd-sysv-utils, but not
hard-host-depends which previously depended on systemd-sysv-utils.
Mixing the older hard-host-depends with the latest systemd creates a
conflict. Fortunately we can work around this by providing the older
ebuild revision with the newer dependency list. Portage will use the
dependency list from the ebuild rather than the installed package.
`hard-host-depends-0.0.1-r170.ebuild` can be removed once the SDK
version is 457.0.0 or later.
Setting environment options in a systemd overlay is not getting
honoured; presumably because those options aren't passed through docker
to flanneld. To work around this, pass arguments explicitly, using an
environment file.
Some minor updates from upstream such as a fix for building without
openssl which doesn't impact our current configuration. Additionally,
our 'examples' use flag was non-functional because 4.2.8 now includes
scripts in its normal build system and installs them to bin. Instead add
a better named 'perl' use flag and patch the build.
By default /usr/share/oem/lib64 is included in ld.so.conf but if for any
reason ld.so.cache is generated incorrectly vmtoolsd will fail. Using
rpath instead avoids depending on the state of ld.so.cache.
This release includes some important security updates:
http://www.kb.cert.org/vuls/id/852879
Also, support for the ntpdc client in ntpd has been removed upstream.
The ntpq client must be used instead.
Minor sync with upstream, adds a use flag we don't enable.
Updated our toolchain just in time, the -fuse-ld= option is now
supported and as of 218 systemd doesn't link with bfd any more so now is
a good time to re-enable the configure test to enable it. For reference
the guilty commit at fault is probably:
5f86c1f4c4
Or specifically:
```c
/* GCC maps this magically to the beginning and end of the BUS_ERROR_MAP section */
extern const sd_bus_error_map __start_BUS_ERROR_MAP[];
extern const sd_bus_error_map __stop_BUS_ERROR_MAP[];
```
... to which I say haha wtf... WELL WHAT ABOUT WHEN IT DOESN'T? :-P
