The soname/identification of libgerbil on darwin is not correctly fixed up,
resulting in any binaries linked with libgerbil to attempt to link to
libgerbil in the temporary build dir from the gerbil derivation. This
means that any compiled gerbil program won't work as the propagated soname
will result in the binary being unable to correctly link with libgerbil.
Adding an Darwin-only step to use `install_name_tool` to fix up the soname
of libgerbil fixes this issue. We're using realpath here as the qualified
path to `libgerbil` is `$out/gerbil/$version/lib/libgerbil.so` and this is
an easier way to obtain the qualified path.
FixesNixOS/nixpkgs#272967.
Without this, it's impossible to override the lockFile as the default
overrideAttrs is applied after the composition in buildNimPackage has
read the lock file and generated the nim flags from it.
this makes it a lot easier to create a modified stdenv with a
different set of defaultHardeningFlags and as a bonus allows us
to inject the correct defaultHardeningFlags into toolchain wrapper
scripts, reducing repetition.
while most hardening flags are arguably more of a compiler thing,
it works better to put them in bintools-wrapper because cc-wrapper
can easily refer to bintools but not vice-versa.
mkDerivation can still easily refer to either when it is constructed.
this also switches fortran-hook.sh to use the same defaults for
NIX_HARDENING_ENABLE as for C. previously NIX_HARDENING_ENABLE
defaults were apparently used to avoid passing problematic flags
to a fortran compiler, but this falls apart as soon as mkDerivation
sets its own NIX_HARDENING_ENABLE - cc.hardeningUnsupportedFlags
is a more appropriate mechanism for this as it actively filters
out flags from being used by the wrapper, so switch to using that
instead.
this is still an imperfect mechanism because it doesn't handle a
compiler which has both langFortran *and* langC very well - applying
the superset of the two's hardeningUnsupportedFlags to either
compiler's invocation. however this is nothing new - cc-wrapper
already poorly handles a langFortran+langC compiler, applying two
setup hooks that have contradictory options.
