Some packages don’t work correctly with pie. Here I disable it for:
- busybox
- linux kernel
- kexectools
I also get rid of the Musl conditional for disabling pie in GCC and
Binutils. Some day we might want to enable PIE without Musl and it
will be useful to have the *just* work with our compiler and linkers.
These don’t like having -fPIE set for them. We should disable
hardening all the time, but in the interest of not changing hashes,
this only disables it for Musl (where it is now the default).
(cherry picked from commit a3a6884649354a660326acd68c1bd08ffd2dcfa2)
In 3027bca, binutils was upgraded from 2.28.1 to 2.30. However, in 2.30,
the ldmain.c file within binutils, which the nixpkgs new-dtags.patch
file is meant to modify, was changed in such a way that the patch no
longer works. As a result, the new dtags are not actually enabled, and
binaries are built with RPATH set instead of RUNPATH, thereby preventing
LD_LIBRARY_PATH from overriding this built-in path. This change corrects
this. The patch file is no longer necessary because binutils's ldmain.c
now sets link_info.new_dtags based on the configuration flags.
This was probably not noticed immediately because, when the derivation
is built with nix-build, the fixupPhase runs patchelf --shrink-rpath.
patchelf converts any RPATH in the binary into RUNPATH (unless
--force-rpath is specified). Of course, if the binary is built without
nix-build (such as in a nix-shell), this never occurs, and any RPATH in
the binary is left in place.
This fails for me:
> compressed_output.cc:320:20: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
> gold_warning(_("not compressing section data: zlib error"));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./system.h:40:20: note: expanded from macro '_'
> # define _(String) gettext (String)
> ^~~~~~~~~~~~~~~~
> compressed_output.cc:320:20: note: treat the string as an argument to avoid this
> gold_warning(_("not compressing section data: zlib error"));
> ^
> "%s",
> ./system.h:40:20: note: expanded from macro '_'
> # define _(String) gettext (String)
^
Disabling format hardening should hopefully be harmless here. If it's a problem we can also make it conditional.
/cc @Ericson2314
And there's more reverts too. The previous commmit
d838afbc9376bdadb8c690eb00b425f3eeccdf2d to gnu-config finally solves
it!
This reverts commit 3ed545ab31.
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
(cherry picked from commit ba52ae5048)
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
