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
"This release should be used instead of 3.0.1. This release fixes
several issues." - http://scons.org/scons-301-is-available.html
More than 90% of the 346 rebuilds succeed without any problems (I've
tested it against aeff3080d0). As far as I
can tell most of the problematic packages either failed before the
upgrade or for a reason that is unrelated to this SCons update. But it
is possible that this'll cause a few regressions, I'll try to watch out
for build failures on Hydra.
The attribute sconsPackages.scons_3_0_0 is still available in case this
breaks anything.
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?!
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.
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
