Rather than `$BASH`, `glibc` now hardcodes `/bin/bash` as
interpreter[1] in several scripts (including `ldd`).
This is a problem because relevant programs such as `ldd(1)` won't work
properly without this since we set `BASH` to `/bin/sh` to avoid
dependencies to the bootstrap tools for `bash` as runtime-dependency (since
NixOS doesn't have `/bin/bash`).
Considering that this was only done as an "improvement" to their
build-system and not because they wanted to use some bashisms here (the
variable was always called `BASH` and we still used `/bin/sh` anyways),
I'd consider this to be relatively safe.
[1] 5188a9d0265cc6f7235a8af1d31ab02e4a24853d
Since the script interpreters are not patched (anymore?), no reference
to any shell is generated by the scripts in glibc's `bin` output:
```
$ nix-store --query --references /nix/store/nmfj3a2k2kr2lypndn37x6qbd8537f9b-glibc-riscv64-unknown-linux-gnu-2.33-50-bin
/nix/store/afgfd3vl3x5zx89awn3fjayn83yl9vcy-glibc-riscv64-unknown-linux-gnu-2.33-50
/nix/store/nmfj3a2k2kr2lypndn37x6qbd8537f9b-glibc-riscv64-unknown-linux-gnu-2.33-50-bin
```
This means that it's safe to include the scripts in glibc's bin output
even in cross builds. One interesting improvement for the future could
be to split these scripts into a separate derivation and properly patch
their script interpreter (currently they are using impure /bin/sh).
`mtrace(1)` is a small Perl script that interprets and provides
human-readable output for `malloc(3)` traces.
Even though this is actually part of `glibc` itself I decided to place
this into its own package. The main reason for this is that this script
has a runtime dependency on Perl which would complicate `stdenv`
bootstrapping since we'd have to compile another Perl that doesn't depend on
the bootstrap tools that is used as runtime dependency for the
stage2 glibc.
Since this is only a dev/debugging tool, splitting this up seemed like a
reasonable choice to me.
On a leaking C program, this can be used like this:
$ env MALLOC_TRACE=$(pwd)/trace ./a.out
$ ./result/bin/mtrace ./trace
Memory not freed:
-----------------
Address Size Caller
0x0000000001875690 0x4 at 0x401151
Closes#141924
Add an explicit dependency on netbase for /etc/protocols
Certain functions in glibc look for files present in /etc such as getprotobyname which reads /etc/protocols.
If you are using Nix over a Linux installation, this file may not be present, and therefore it will cause errors.
- add netbase as a new package in nixpks
- add a dependency in glibc on it using postPatchPhase and substitute
the path
Fixes#124401
This enables ALSR on static executables, which makes them harder to
exploit by providing a crt suitable for static PIEs.
Does this break existing binaries? Likely not. Static-pie is only
used if explicitly enabled.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
Fixes cross-compilation when build == host != target == ppc64le.
Glibc invokes objcopy during cross-compilation to ppc64le, which
fails when the nonprefixed objcopy can't understand the target format.
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).
Maximilian Bosch