On aarch64 we "leak" a reference to $out/lib/systemd/catalog in the lib
output. The result of that is a dependency cycle between $out and $lib.
Thus nix (rightfully) marks the build as failed. That reference
originates from an array of strings (catalog_file_dirs) in systemd
(src/src/journal/catalog.{c,h}). The only consumer (as of v242) of the
symbol is the main function of journalctl. Still libsystemd.so contains
the VALUE but not the symbol. Systemd seems to be properly using
function & data sections together with the linker flags to garbage
collect unused sections (-Wl,--gc-sections). For unknown reasons those
flags do not eliminate the unused string constants, in this case on
aarch64-linux. The hacky way is to just remove the reference after we
finished compiling. Since it can not be used (there is no symbol to
actually refer to it) there should not be any harm. It is a bit odd and
I really do not like starting these kind of hacks but there doesn't seem
to be a straight forward way at this point in time.
The reference will be replaced by the same reference the usual nukeRefs
tooling uses. The standard tooling can not / should not be uesd since
it is a bit too excessive and could potentially do us some (more) harm.
We are currently not running any tests but building them takes
signitifcant amounts of time since they account to about 40% of all the
compilation targets.
The current approach will fail when enough time has passed. We ideally
want to be reproducible even in a few years of time. So we should pick
the sources of patches wisely as otherwise we can not do that.
Fixes CVE-2018-15688 and updates latest upstream stable v239 branch.
See https://github.com/NixOS/systemd/pull/24 for details.
Co-authored-by: Andreas Rammhold <andreas@rammhold.de>
meson 0.46 no longer likes receiving both -Dmandir and --mandir. I removed the flags from the expression in favour of those in the meson setup hook. This also fixes manpages which were previously
installed to $man/lib for some reason.
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
The isSeccomputable flag treated Linux without seccomp as just a
normal variant, when it really should be treated as a special case
incurring complexity debt to support.
The isKexecable flag treated Linux without kexec as just a normal
variant, when it really should be treated as a special case incurring
complexity debt to support.
