Hooks are essentially implemented as special shell packages that run on
their respective host platform. When they are used, they appear as
nativeBuildInputs (as they need to be executed as part of the build of a
package using them) so are taken from buildPackages relative to the
derivation using them.
Since the override in buildNpmPackage nullifies splicing, we take
npmHooks from buildPackages manually.
Fixes pkgsCross.ghcjs.buildPackages.emscripten and thus
pkgsCross.ghcjs.haskellPackages.ghc.
I do not think there is a good reason for it to be optional.
There were only two packages without a version attr. The version attr
is added to them in this patch.
The first log in *Message* before this patch:
Loading /nix/store/bikm18vy6v07hmrvrll501i68440w9iw-emacs-29.1-rc1/share/emacs/site-lisp/site-start.el (source)...done
and after this patch:
Loading /nix/store/bikm18vy6v07hmrvrll501i68440w9iw-emacs-29.1-rc1/share/emacs/site-lisp/site-start (native compiled elisp)...done
I see no reason to symlink this dir.
Doing so may shadow unwanted libraries since the site-start.el of
Emacs adds paths under NIX_PROFILES to load-path.
It is added in [1] to fix "building emacs". However, I have no issue
in building and using Emacs after removing it.
[1]: https://github.com/NixOS/nixpkgs/pull/89351
"$out/share/emacs/site-lisp" is added to load-path in wrapper.sh[1]
using EMACSLOADPATH and "$out/share/emacs/native-lisp/" is added to
native-comp-eln-load-path in wrapper.sh[2] using
EMACSNATIVELOADPATH. There is no point to add them again here.
Additionally, the trailing "/" in "$out/share/emacs/native-lisp/"
causes duplicate entries in native-comp-eln-load-path:
("/nix/store/hash1-emacs-packages-deps/share/emacs/native-lisp/" ; [3]
"/home/user/.emacs.d/eln-cache/"
"/nix/store/hash1-emacs-packages-deps/share/emacs/native-lisp" ; [2]
"/nix/store/hash2-emacs-29.1-rc1/lib/emacs/29.1/native-lisp/")
load-path does not change with this patch applied.
[1]: 1476c13422/pkgs/build-support/emacs/wrapper.sh (L47)
[2]: 1476c13422/pkgs/build-support/emacs/wrapper.sh (L50)
[3]: 1476c13422/pkgs/build-support/emacs/wrapper.nix (L166)
Add this hook to checkPhase to allow for running MPI application in
the sandbox. It detects the MPI implementations and sets the respective
environment variables.
Before the change the following command did not work:
$ nix develop -i --impure --expr 'with import <nixpkgs> { system = "i686-linux"; }; (buildFHSUserEnv { name = "t"; targetPkgs = ps: with ps; [ libmpc stdenv.cc ]; }).env'
$ ld -lmpc -o a
ld: cannot find -lmpc: No such file or directory
It is expected to work as `NIX_LDFLAGS` does contain valid values:
$ echo $NIX_LDFLAGS
-L/usr/lib -L/usr/lib32
Note that for `gcc` it does work:
$ printf "int main(){}" | gcc -x c - -lmpc -o a
It happens because `HOST` role is enabled for `cc`:
$ echo $NIX_CC_WRAPPER_TARGET_HOST_i686_unknown_linux_gnu
1
But not for `BINTOOLS`:
$ echo $NIX_BINTOOLS_WRAPPER_TARGET_HOST_i686_unknown_linux_gnu
<empty>
The change adds BINTOOLS role and fixes linking:
$ nix develop -i --impure --expr 'with import ~/nm { system = "i686-linux"; }; (buildFHSUserEnv { name = "t"; targetPkgs = ps: with ps; [ libmpc stdenv.cc ]; }).env'
$ printf "int main(){}" | gcc -x c - -lmpc -o a
$ ld -lmpc -o a
ld: warning: cannot find entry symbol _start; not setting start address