emacsGcc deffered compliation fails about emacs-overlay

[mjlbach]

The fix is still in staging; it will take a bit for it to end up in nixpkgs

[jkachmar]

I might be misreading, but that thread seems to point to additionally exposed functionality (cf. this diff) which appears to allow for options to be passed directly to the native compiler backend from within Emacs.

My understanding is that it would bypass the need to mess with LIBRARY_PATH entirely in this situation (although, again, I could be mistaken).

[mjlbach]

I'm using nix + home-manager on Fedora

[mjlbach]

@adisbladis should this be reopened? I don't know when it happened, but my native-compilation has been silently failing via straight.el/doom even when setting LIBRARY_PATH

[mjlbach]

This should be fixed by this change https://github.com/NixOS/nixpkgs/pull/94637/files#diff-66d54fc5596a4650473b8b4049520905R70-R75

closed by this PR NixOS/nixpkgs#94637

[adisbladis]

This has now hit unstable!

Thank you @antifuchs!

[mjlbach]

This is because gcc can't find the libgccjit libraries at (deferred) compilation time. If you want that, you need to update LIBRARY_PATH to point at the right libraries. If you evaluate the following in nix-repl, you should get the right paths (then you can update with LIBRARY_PATH=...)

pkgs.lib.getLib pkgs.stdenv.cc.cc + /lib
pkgs.lib.getLib pkgs.stdenv.glibc + /lib 
pkgs.lib.getLib pkgs.libgccjit + /lib/gcc/x86_64-unknown-linux-gnu/9.3.0

[adisbladis]

To add to what @mjlbach is saying, I don't want to add LIBRARY_PATH in a wrapper as it pollutes the development environment, instead I'd like to set it for the native-comp subprocess.

[akirakyle]

@mjlbach Thanks! That appears to have done the trick! This should probably be documented somewhere.

@adisbladis That makes sense. I wonder if the overlay should include some startup lisp which adds a hook to the native comp function to set the LIBRARY_PATH and ensure binutils is present just for the native-comp subprocess so that emacs' environment isn't polluted but a user can also safely keep comp-deferred-compilation set?

Perhaps @AndreaCorallo might even be willing expose some interface to make this easier?

[adisbladis]

@akirakyle Yes, that's what I've been thinking too.

[AndreaCorallo]

I think you guys could use comp-async-env-modifier-form to execute the lisp you want in the environment of the async compilation process. Is not much tested but sounds like what you need.

Note the synchronous compilation will still be crashy in case is used.

[mjlbach]

@AndreaCorallo Thanks, this seems to work for me (not sure if this is correct though, I'm a complete emacs novice):

(setq comp-async-env-modifier-form '((setenv "LIBRARY_PATH"
                                             (concat
        "/nix/store/wfvfxj1w9gj21nbai6rsyhwvkbqf59w0-libgccjit-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0:"
        "/nix/store/a6z7ighixg7gb6krf9k60ylgmahij63x-gcc-9.3.0-lib/lib:"
        "/nix/store/jx19wa4xlh9n4324xdl9rjnykd19mmq3-glibc-2.30/lib:"
        )
  )))

I'm not sure if there's a cleaner way to do this, but I used nix eval to get the paths at build time as such:

(setq comp-async-env-modifier-form '((setenv "LIBRARY_PATH"
                                             (concat
        (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in with pkgs; stdenv.lib.makeLibraryPath [stdenv.cc.cc stdenv.glibc])'")
        ":"
        (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in with pkgs; lib.getLib libgccjit + /lib/gcc/x86_64-unknown-linux-gnu/9.3.0 )'"))
)))

[spacekitteh]

Is there any update on this?

[mjlbach]

@spacekitteh Did the solution I post not work for you?

[spacekitteh]

Nope:
Invalid function: (setenv "LIBRARY_PATH" (concat (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in (pkgs.lib.getLib pkgs.libgccjit + /lib/gcc/x86_64-unknown-linux-gnu/9.3.0:)'") (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in (pkgs.lib.getLib pkgs.stdenv.cc.cc + /lib)'") (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in (pkgs.lib.getLib pkgs.stdenv.glibc + /lib)'")))

[mjlbach]

Sorry, try this instead.

(setq comp-async-env-modifier-form '((setenv "LIBRARY_PATH"
                                             (concat
        (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in with pkgs; stdenv.lib.makeLibraryPath [stdenv.cc.cc stdenv.glibc])'")
        ":"
        (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in with pkgs; lib.getLib libgccjit + /lib/gcc/x86_64-unknown-linux-gnu/9.3.0 )'")))))

[spacekitteh]

Nope, still getting Invalid function.

[mjlbach]

This is my output from ielm:

ELISP> (setenv "LIBRARY_PATH"
                                             (concat
        (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in with pkgs; stdenv.lib.makeLibraryPath [stdenv.cc.cc stdenv.glibc])'")
        ":"
        (shell-command-to-string "nix eval --raw '(let pkgs = import <nixpkgs> {}; in with pkgs; lib.getLib libgccjit + /lib/gcc/x86_64-unknown-linux-gnu/9.3.0 )'")))
"/nix/store/a6z7ighixg7gb6krf9k60ylgmahij63x-gcc-9.3.0-lib/lib:/nix/store/jx19wa4xlh9n4324xdl9rjnykd19mmq3-glibc-2.30/lib:/nix/store/wfvfxj1w9gj21nbai6rsyhwvkbqf59w0-libgccjit-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0"

[spacekitteh]

Am I missing a require or anything?

[spacekitteh]

I use use-package, does that not play nicely or something?

[akirakyle]

@spacekitteh Not sure if it's related to the issue you're seeing here but there was a bug with use-package that prevented using native-comp that was fixed a bit ago so you might try updating use-package, see here for some details.

[spacekitteh]

Could it be because I unfortunately don't use NixOS, but nix+home-manager on Ubuntu?

[spacekitteh]

It works in *scratch*, but not when setting it as comp-async-env-modifier-form.

[adisbladis]

Sure, I'll reopen.
But I will not be debugging this myself as I only ever use Nix for Emacs package management.

[mjlbach]

Yes, I'm happy to look into this :)

[mjlbach]

Ok, so the issues is a bit more complicated.

@AndreaCorallo It seems like if you launch emacs with the correct LIBRARY_PATH, native compilation works fine:

LIBRARY_PATH=/nix/store/rnx85wkx3fdrwmj5x1s4h31jqr50l8s1-gcc-9.3.0-lib/lib:/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib:/nix/store/0dknchqiha9mvzhy6m3xmyzl3g2zc7av-libgccjit-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0  emacs

If you set comp-async-env-modifier-form to:

(setq comp-async-env-modifier-form `(setenv "LIBRARY_PATH" "/nix/store/rnx85wkx3fdrwmj5x1s4h31jqr50l8s1-gcc-9.3.0-lib/lib:/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib:/nix/store/0dknchqiha9mvzhy6m3xmyzl3g2zc7av-libgccjit-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0"))

Native-compilation fails. Under the hood, the async-native-comp function is just launching a bunch of workers evaluating comp-async-env-modifier form before calling native-comp, however, the following fails to compile under nix. And just outputs empty *.eln files (with debugging on the c intermediate is output fine).

(setenv "LIBRARY_PATH" "/nix/store/rnx85wkx3fdrwmj5x1s4h31jqr50l8s1-gcc-9.3.0-lib/lib:/nix/store/7p1v1b6ys9fydg5kdqvr5mpr8svhwf4p-glibc-2.31/lib:/nix/store/0dknchqiha9mvzhy6m3xmyzl3g2zc7av-libgccjit-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0")
(native-compile "/home/michael/.emacs.d/.local/straight/build/dash/dash.el")

It seems like we can't set the LIBRARY_PATH from within emacs for native-comp, so people will likely have to wrap emacs unless this is fixed upstream.

[AndreaCorallo]

Do you get any more specific error on the console or in the 'Async-native-compile-log' buffer?

[mjlbach]

Yes, it's not finding the libgcc libraries it seems:

When I invoke native-comp (not async) directly setting LIBRARY_PATH within emacs:

/nix/store/k6rnzlmcvm37d0nw4fkz6ivmykmrdn39-binutils-2.31.1/bin/ld: cannot find crti.o: No such file or directory
/nix/store/k6rnzlmcvm37d0nw4fkz6ivmykmrdn39-binutils-2.31.1/bin/ld: cannot find crtbeginS.o: No such file or directory
/nix/store/k6rnzlmcvm37d0nw4fkz6ivmykmrdn39-binutils-2.31.1/bin/ld: cannot find -lgcc
/nix/store/k6rnzlmcvm37d0nw4fkz6ivmykmrdn39-binutils-2.31.1/bin/ld: cannot find -lgcc
libgccjit.so: error: error invoking gcc driver

Async native compiler log:

Loading /nix/store/c27zvaqcdjviss061zcb1mny5bncpsyv-emacs-gcc-20200726.0/share/emacs/site-lisp/site-start.el (source)...
Loading /nix/store/c27zvaqcdjviss061zcb1mny5bncpsyv-emacs-gcc-20200726.0/share/emacs/site-lisp/site-start.el (source)...
Loading /nix/store/c27zvaqcdjviss061zcb1mny5bncpsyv-emacs-gcc-20200726.0/share/emacs/site-lisp/site-start.el (source)...
Compiling /home/michael/.emacs.d/.local/straight/build/yasnippet/yasnippet.el...
Compiling /home/michael/.emacs.d/.local/straight/build/xterm-color/xterm-color.el...
Compiling /home/michael/.emacs.d/.local/straight/build/yasnippet/yasnippet-autoloads.el...
empty byte compiler output: "/home/michael/.emacs.d/.local/straight/build/yasnippet/yasnippet-autoloads.el", "/home/michael/.emacs.d/.local/straight/build/yasnippet/yasnippet-autoloads.el"
Loading /nix/store/c27zvaqcdjviss061zcb1mny5bncpsyv-emacs-gcc-20200726.0/share/emacs/site-lisp/site-start.el (source)...
Compiling /home/michael/.emacs.d/.local/straight/build/xterm-color/xterm-color-autoloads.el...
empty byte compiler output: "/home/michael/.emacs.d/.local/straight/build/xterm-color/xterm-color-autoloads.el", "/home/michael/.emacs.d/.local/straight/build/xterm-color/xterm-color-autoloads.el"

All of the *.eln files are empty, and then emacs segfaults after compiling a few

[AndreaCorallo]

Mmmh I see, this looks strange.
So the exact same LIBRARY_PATH value if set before starting emacs does the job?

[mjlbach]

Yes, exactly. We can also wrap emacs so that it effectively passes the library_path on each startup but as @adisbladis pointed out this will make all subprocesses launched by emacs impure as they will then pass this library_env to all child processes

[jkachmar]

On the off chance that y'all may not have seen this, it seems that when/if this enhancement lands it sounds like we should be able to sidestep this problem entirely:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42761

[mjlbach]

Yeah, I was following. As I noted above, even if we set LIBRARY_PATH via comp-async-env-modifier-form we still can't native-compile packages (under async workers, sync doesn't invoke this so would not work to begin with). Currently LIBRARY_PATH is set incorrectly in nixpkgs, I have a PR to fix this, but as mentioned it doesn't solve the problem because gcc doesn't pick up the LIBRARY_PATH set from within emacs.

See: NixOS/nixpkgs#94154

[matthew-piziak]

When I load (setq comp-deferred-compilation t) I simply get the following:

Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20200721.2156/eln-x86_64-pc-linux-gnu-815168410c73dd5c/use-package-core.eln skipping. [91 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/bind-key-20200805.1727/eln-x86_64-pc-linux-gnu-815168410c73dd5c/bind-key.eln skipping. [5 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20200721.2156/eln-x86_64-pc-linux-gnu-815168410c73dd5c/use-package-bind-key.eln skipping. [6 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20200721.2156/eln-x86_64-pc-linux-gnu-815168410c73dd5c/use-package-diminish.eln skipping. [3 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20200721.2156/eln-x86_64-pc-linux-gnu-815168410c73dd5c/use-package-delight.eln skipping. [3 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/use-package-20200721.2156/eln-x86_64-pc-linux-gnu-815168410c73dd5c/use-package-ensure.eln skipping. [7 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/delight-1.7/eln-x86_64-pc-linux-gnu-815168410c73dd5c/delight.eln skipping. [5 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/s-20180406.808/eln-x86_64-pc-linux-gnu-815168410c73dd5c/s.eln skipping. [69 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/exec-path-from-shell-20200526.324/eln-x86_64-pc-linux-gnu-815168410c73dd5c/exec-path-from-shell.eln skipping. [12 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/el-patch-20200716.1428/eln-x86_64-pc-linux-gnu-815168410c73dd5c/el-patch.eln skipping. [21 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/request-20200517.1305/eln-x86_64-pc-linux-gnu-815168410c73dd5c/request.eln skipping. [82 times]
Warning (comp): No write access for /nix/store/kl5nkajk79p2wg8xiy4f354xmlxvhxis-emacs-packages-deps/share/emacs/site-lisp/elpa/diminish-20191127.1326/eln-x86_64-pc-linux-gnu-815168410c73dd5c/diminish.eln skipping. [3 times]
…

[willbush]

For what it's worth, I'm getting the following error:

Invalid function: (setenv "LIBRARY_PATH" (string-join (seq-filter (lambda (v) (null (eq v nil))) (list (getenv "LIBRARY_PATH") "/nix/store/y97bkww2pnxnqd2kwprlbw3ji4ib4d1w-libgccjit-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0:/nix/store/v589pqjhvxrj73g3r0xb41yr84z5pwb7-gcc-9.3.0-lib/lib:/nix/store/mh78fk3x12q2a77srgkzv16h0irl8r61-glibc-2.31/lib")) ":"))

After I updated NixOS to the latest on the nixos-unstable channel and updated the emacs-overlay to the latest (currently rev 943ec43e54f5152c4d5d8d0076e72beea9a7ff5a in the master branch).

[spacekitteh]

As of this morning, emacsGcc to no longer launches properly for me on NixOS. I'm not sure if it's related to this or not.

[willbush]

What error are you getting?

[spacekitteh]

Nevermind - I had to delete my ~/.emacs.d/eln-cache folder.