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`.
Feature rich browser-based frontend with data structure visualizations
(like DDD), and gdb terminal access. Compatible with C, C++, golang,
Rust, fortran. Written in Python and JavaScript
gdbgui is at the top of the GDB Front Ends
list on https://sourceware.org/gdb/wiki/GDB%20Front%20Ends
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
The biggest benefit is that we no longer have to update the registry
package. This means that just about any cargo package can be built by
nix. No longer does `cargo update` need to be feared because it will
update to packages newer then what is available in nixpkgs.
Instead of fetching the cargo registry this bundles all the source code
into a "vendor/" folder.
This also uses the new --frozen and --locked flags which is nice.
Currently cargo-vendor only provides binaries for Linux and
macOS 64-bit. This can be solved by building it for the other
architectures and uploading it somewhere (like the NixOS cache).
This also has the downside that it requires a change to everyone's deps
hash. And if the old one is used because it was cached it will fail to
build as it will attempt to use the old version. For this reason the
attribute has been renamed to `cargoSha256`.
Authors:
* Kevin Cox <kevincox@kevincox.ca>
* Jörg Thalheim <Mic92@users.noreply.github.com>
* zimbatm <zimbatm@zimbatm.com>
