This bug was preventing one compiling Haskell programs from `pkgsMusl` for
armv7.
`nix-build --argstr crossSystem "armv7l-linux" -A pkgsMusl.haskellPackages.hello`
succeeds with this patch.
The patch is Nick Clifton's one, rebased by @ericson2314 here
https://sourceware.org/bugzilla/show_bug.cgi?id=16177#c6
Although there was some talk about the efficacy of the binutils patch
(https://sourceware.org/bugzilla/show_bug.cgi?id=16177#c9) the resulting
binary seems to run without issue on the target platform. Jessica's
patch there caused ld to fail linking some programs. Nick's proposed
patch has worked well in my testing so far (a Haskell project of some
small complexity cross compiled with musl to armv7).
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
Pythons find_library is broken with binutils 2.34, and numpy could not import libraries because of not properly aligned ELF's.
This is the second time binutils 2.34 got reverted. Next time, we should have a dedicated Hydra job for it.
This reverts commit 629fa8a2d4, reversing
changes made to 4ddd080d19.
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
This commit breaks native armv7l-linux builds. Revert it until it can
be root-caused. This reversion does not affect other platforms or
cross-compiling.
This reverts commit 0f5c804631.
Now that we do `--enable-targes=all`, there is no risk of missing the
needed emulation.
This reverts commit ebc9b161cd.
This reverts commit 88efc22b44.
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
https://github.com/NixOS/nixpkgs/pull/30484#issuecomment-345472766
Since [1] libbfd is compiled with support for all available targets. However, it
can not choose whether an ARM ELF file is elf32-littlearm,
elf32-littlearm-symbian, or elf32-littlearm-vxworks, and fails with the "File
format is ambiguous" error. Here [2] Alan Modra intended to prioritize the
first of the three, but although his patch was merged and reportedly solved the
issue, currently glibc 2.28.1 and 2.29.1 again fail to disambiguate these
targets. This commit makes it prioritize elf32-littlearm over the other two.
[1] f8741c38cd
[2] https://sourceware.org/ml/binutils/2013-05/msg00271.html
There are separate derivations for these libraries and we don't want
conflict. Multitarget is generally more useful, and will eventually
speed up cross builds, so why not?!
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
This is needed for build != host == target builds. Moreoever, we want
to move towards always passing all 3, and the previous change to
unbreak Arm moved us away from that.
We want platform triple prefixes and suffixes on derivation names to
be used consistently. The ideom this commit strives for is
- suffix means build != host, i.e. cross *built* packages. This is
already done.
- prefix means build != target, i.e. cross tools. This matches the
tradition of such binaries themselves being prefixed to disambiguate.]
Binutils and cctools, as build tools, now use the latter
- No more *Cross duplication for binutils on darwin either.
`cctools_cross` is merged into plain `cctools`, so `buildPackages`
chains alone are used to disambiguate.
- Always use a mashup of cctools and actual GNU Binutils as `binutils`.
Previously, this was only done in the native case as nobody had
bothered to implement the masher in the cross case. Implemented it
basically consisted of extending the wrapper to deal with prefixed
binaries.
The old forms presumably predates, or were made in ignorance of,
`let inherit`. This way is better style as the scoping as more lexical,
something which Nix can (or might already!) take advantage of.
