search

alexmurray / emacs-snap

GNU Emacs in a snap
https://snapcraft.io/emacs
71 stars 13 forks source link

Linker error on emacs-snapshot (triggered by doom-emacs) #22

Closed rassie closed 3 years ago

rassie commented 3 years ago

I'm trying out the nativecomp snap (28.0.50-native-comp-d5791ba) and get this error when I try to update doom-emacs's configuration:

ld: cannot find crtbeginS.o: No such file or directory
ld: cannot find -lgcc
ld: cannot find -lgcc_s
libgccjit.so: error: error invoking gcc driver
alexmurray commented 3 years ago

Thanks for reporting this issue - I don't use Doom emacs though so I haven't seen anything like this.. can you explain how I could try and reproduce this to try and debug it?

rassie commented 3 years ago

I can reproduce the problem by cloning the doom-emacs repository and starting installation (it's only touching its own working directory, so no data corruption should be expected):

$ git clone https://github.com/hlissner/doom-emacs
Cloning into 'doom-emacs'...
remote: Enumerating objects: 82, done.
remote: Counting objects: 100% (82/82), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 92720 (delta 40), reused 20 (delta 10), pack-reused 92638
Receiving objects: 100% (92720/92720), 22.69 MiB | 3.38 MiB/s, done.
Resolving deltas: 100% (65531/65531), done.

$ cd doom-emacs

$ bin/doom install
Installing straight...
Cloning use-package...
Cloning use-package...done
Building use-package...
Building use-package -> Building bind-key...
Building use-package -> Building bind-key...done
Building use-package...
Building use-package...done
ld: cannot find crtbeginS.o: No such file or directory
ld: cannot find -lgcc
ld: cannot find -lgcc_s
libgccjit.so: error: error invoking gcc driver
ld: cannot find crtbeginS.o: No such file or directory
ld: cannot find -lgcc
ld: cannot find -lgcc_s
libgccjit.so: error: error invoking gcc driver
No catch for tag: exit, 255
rassie commented 3 years ago

Oh, FWIW, I'm on Ubuntu 18.04 if that matters with snaps at all.

alexmurray commented 3 years ago

Is this specific to the emacs feature/native-comp snap - ie. if you compile emacs from the feature/native-comp branch manually can you also reproduce this?

rassie commented 3 years ago

I haven't tried compiling myself, always used PPAs or snaps. However, AFAIK people are using doom-emacs with the native-comp branch, so I assume it's something snap-related.

alexmurray commented 3 years ago

I think this should be fixed now - the snap is rebuilding and should be available on the edge channel in an hour or so - @rassie let me know if this doesn't fix it for you.

rassie commented 3 years ago

Thanks, will test ASAP!

rassie commented 3 years ago

@alexmurray there seems to be no update from today (yet?), but there is a build based on the right commit, built on 30th of October. An update on the snap installs version 28.0.50-native-comp-fd9e930 revision 921, which still exhibits the problem. Do I have the right one or is there another build upcoming in the pipeline?

alexmurray commented 3 years ago

Oh I see, doom sets --no-site-lisp so the fix in 77f7f16 is skipped... I'll see if we can do this in a more permanent manner...

alexmurray commented 3 years ago

Unfortunately there doesn't appear to be a good way to resolve this easily in the case of doom - I have added an additional fix in b6cabbce252884d72cf8df9bc6c76cc5aebbae1e and 8852e3e2bdba7c6506538c8812fc8900ed99f8d9 but this is still mooted by doom's use of --no-site-file when compiling it's elisp. doom can be made to work though via the following as of 8852e3e2bdba7c6506538c8812fc8900ed99f8d9:

git clone https://github.com/hlissner/doom-emacs
cd doom-emacs
sed -i 's/--no-site-file//' bin/doom
./bin/doom install

(ie simply removing it's use of --no-site-file when invoking emacs as we rely on the site-file to tell the native-compiler where to find the snapped gcc libraries etc)

A new build should be available within the next hour on the edge channel with this fix.

rassie commented 3 years ago

@alexmurray Thanks! I've opened an issue with doom-emacs, maybe there is some middle ground that could be found to avoid workarounds like these.

hlissner commented 3 years ago

Is removing --no-site-file truly necessary with this line present in bin/doom? Perhaps it can be adjusted instead of removing --no-site-file?

alexmurray commented 3 years ago

emacs-snap relies on the site file to ensure the native comp environment specifies gcc etc shipped inside the snap. doom-emacs fails to install when --no-site-file is present so in this case removing this is necessary - can I ask why you think it is necessary to use this flag for doom-emacs?:

$ sudo snap install emacs --edge --classic
$ git clone https://github.com/hlissner/doom-emacs
$ cd doom-emacs
$ ./bin/doom install
Installing straight...
Cloning use-package...
Cloning use-package...done
Building use-package...
Building use-package → Building bind-key...
Building use-package → Building bind-key...done
Building use-package...
Building use-package...done
ld: cannot find crti.o: No such file or directory
ld: cannot find crtbeginS.o: No such file or directory
ld: cannot find -lgcc
ld: cannot find -lgcc_s
ld: cannot find -lc
ld: cannot find -lgcc
ld: cannot find -lgcc_s
ld: cannot find crtendS.o: No such file or directory
ld: cannot find crtn.o: No such file or directory
libgccjit.so: error: error invoking gcc driver
ld: cannot find crti.o: No such file or directory
ld: cannot find crtbeginS.o: No such file or directory
ld: cannot find -lgcc
ld: cannot find -lgcc_s
ld: cannot find -lc
ld: cannot find -lgcc
ld: cannot find -lgcc_s
ld: cannot find crtendS.o: No such file or directory
ld: cannot find crtn.o: No such file or directory
libgccjit.so: error: error invoking gcc driver
No catch for tag: exit, 255
$ rm -rf .local/
$ sed -i 's/--no-site-file//' bin/doom
$ ./bin/doom install
Installing straight...
Cloning use-package...
Cloning use-package...done
Building use-package...
Building use-package → Building bind-key...
Building use-package → Building bind-key...done
Building use-package...
Building use-package...done
Installing Doom Emacs!

> Creating .doom.d/
  ✓ Created .doom.d/
- Creating .doom.d/init.el
✓ Done!
- Creating .doom.d/config.el
✓ Done!
- Creating .doom.d/packages.el
✓ Done!
Generate an envvar file? (see `doom help env` for details) (y or n) n
Installing plugins
> Installing packages...
  > Updating recipe repos...
^C  > Updating recipes for melpa...
...
hlissner commented 3 years ago

can I ask why you think it is necessary to use this flag for doom-emacs?

  1. To suppress stdout/stderr from site packages. On some systems we're talking about dozens of lines of noise, sometimes repeated when our CLI restarts. It's noise I don't want our users worrying about.

  2. To prevent impolite site packages from doing destructive things before we're prepared to handle them. e.g. mu's site files on Gentoo would eagerly load the built-in version of org, which interferes with the byte-compilation of newer versions of org later in that session.

emacs-snap relies on the site file to ensure the native comp environment specifies gcc etc shipped inside the snap.

This is what confuses me. I've accounted for this with the line I linked earlier. It successfully loads the site-files in all the environments I've tested on (mainly arch, nixos, ubuntu, and macOS). (load "site-start") is precisely what Emacs itself does to load its site files.

The only way I see this failing is either:

  1. This snap's site-lisp directory somehow didn't make it into Emacs' load-path (which doesn't make sense; Emacs wouldn't be able to find it normally, otherwise).
  2. Something is being queued for native compilation during initialization (before bin/doom executes).

Is there a snap envvar exported to the Emacs process (perhaps SNAP_ARCH?) I can look out for? Perhaps one that'd contain the path of the running snap, so our CLI could add it to load-path? Otherwise, I could conditionally remove --no-site-file depending on its presence.