Darling has a case conflict which means that its src hash will be
different between case sensitive and case insensitive file systems.
This is not ideal and the only way around it is basically to remove
the offending files from the output. I use fetchzip here to do that
but I hope there is a better fix available eventually.
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
Source master rebase of my [PR #34].
Eventually, we might consider doing something for GNU binutils too, in
order that we switch (the normal) ld-wrapper to always use this to
leverage ld to resolve libraries, rather than faking it in bash.
[PR #34]: https://github.com/tpoechtrager/cctools-port/pull/34
Since at least d7bddc27b2, we've had a
situation where one should depend on:
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables,
regardless of the host platform, at run time.
and that commit cleaned up this usage to reflect that. This PR flips the
switch so that:
- `binutils` is indeed unconditionally GNU Binutils
- `binutils-raw`, which previously served that role, is gone.
so that the correct usage will be enforced going forward and everything
is simple.
N.B. In a few cases `binutils-unwrapped` (which before and now was
unconditionally actual GNU binutils), rather than `binutils` was used to
replace old `binutils-raw` as it is friendly towards some cross
compilation usage by avoiding a reference to the next bootstrapping
change.
Among other things, this will allow *2nix tools to output plain data
while still being composable with the traditional
callPackage/.override interfaces.
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`.
- Give cctools a dev output for the headers
- Update Libsystem to grab the headers from that dev output
- Don't include the headers in Darwin binutils, just as GNU Binutils no
longer does.
This includes adding a new xcbuild-based libutil build to test the waters a bit there.
We'll need to get xcbuild into the stdenv bootstrap before we can make the main build,
but it's nice to see that it can work.
This requires some small changes in the stdenv, then working around the
weird choice LLVM made to hardcode @rpath in its install name, and then
lets us remove a ton of annoying workaround hacks in many of our Go
packages. With any luck this will mean less hackery going forward.
This reverts commit 0a944b345e, reversing
changes made to 61733ed6cc.
I dislike these massive stdenv changes with unclear motivation,
especially when they involve gratuitous mass renames like NIX_CC ->
NIX_BINUTILS. The previous such rename (NIX_GCC -> NIX_CC) caused
months of pain, so let's not do that again.
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
The main changes are in libSystem, which lost the coretls component in 10.13
and some hardening changes that quietly crash any program that uses %n in
a non-constant format string, so we've needed to patch a lot of programs that
use gnulib.
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.
This also fixes a missing header in the SDK that rtags needs to work
properly. The underlying cause is that C++ headers got shuffled around a
lot in libc++ 3.8 (I believe) and became more standards-compliant, which
led to a lot of C-compatible passthrough header files being added to it
like math.h, which defines some C++-compatible versions of standard
functions like signbit, while #include_next'ing the system math.h. In
this case, including the SDK was stuffing another math.h in front of the
libc++ shim, which led to all sorts of mysterious failures.
This sort of thing is going to get revamped to be less hackish soon but
for now I want it to work. In this particular case, libc++ 4 (and maybe
earlier) gets very upset if we're imprecise about our const markers, and
I guess libauto was careless. This fixes it (PtrPtrMap) to be correct.
