collares
commented
3 years ago nixos-unstable advanced since you filed the issue. Is this still a problem?
Closed thomasheartman closed 3 years ago
collares
commented
3 years ago nixos-unstable advanced since you filed the issue. Is this still a problem?
lambdadog
commented
3 years ago Honestly a libgccjit.so error doesn't feel like an error in your config, given that native-comp runs prior to actually loading any of the user's config (an issue I bumped into in one of my projects -- since I package my config
in a nix derivation, it couldn't find a directory that was writable to perform compilation in and I had to set one in an environmental variable since it couldn't be set early enough in elisp).
It seems that this is an error invoking the embedded driver specifically, seeing as the error is "error invoking gcc driver" with nothing following it (extra context is provided when loading an external driver fails, example vs the error I'm fairly certain you've gotten), but I'm not particularly familiar with libgccjit or even C, frankly, so I can't really say more.
thomasheartman
commented
3 years ago @collares Thanks for the suggestion! I just tried again now, but I still get the same error.
@lambdadog Ooh, that's really interesting; thanks for the input! I tried a few things now and I'm really now sure what to make of it, but it seems like my config might trigger it (though might just be a symptom, not a cause):
I tried running a few variations now (didn't think of this earlier; sorry):
emacs -Q runs fine. No messages and no warnings.
emacs -q gets similar error messages as running it with my config, but less wordy.
Running emacs-Q -l ~/.emacs.d/straight/repos/straight.el/bootstrap.el (the recommended way to start Emacs with straight.el reday) gives the same errors as above. (I use straight, so thought this might be relevant).
Running emacs with my configuration does work to some extent, though it fails at some point: it prints messages and it sets the custom theme that I use in my config. Here's the full error log. Most of it seems to be the same error as mentioned above with not being able to invoke libgcc, but some errors are also unique for using my config.
I don't have time to research this further today, but I'll see what I can find tomorrow. Also, it seems that this isn't really a config problem as the same config runs fine when using 27.1 (though I have noticed some things not being applied properly 🤔 ), but rather that it just triggers the error a lot more.
Again: thanks very much for your time and input!
lambdadog
commented
3 years ago @thomasheartman To my knowledge the main difference between loading with emacs -Q and emacs -q is that -Q also excludes site-start.el, which nixpkgs sets.
My assumption is that emacs -Q is just giving libgccjit no elisp to chew on, since all of the packages included with emacs are precompiled by the derivation and don't require any runtime invocation of libgccjit.
This reinforces my view that it's some error with libgccjit on your system, but I'm not sure how to isolate it enough that we could take it upstream to gcc (or perhaps nixpkgs, as there could be something wrong with the packaging?). If it's a gcc upstream issue then I'd take it to the emacs mailing list and see if someone could help getting it to a reproducible case, but given that it could be on nixpkgs' end, I'm not sure how to get to that point.
collares
commented
3 years ago I thought this would be fixed by the channel update because comp-native-driver-options, which is patched by nixpkgs, was renamed to native-comp-driver-options. Weird that it isn't fixed... Are you using a recent version of the overlay too? Both should be updated.
thomasheartman
commented
3 years ago @lambdadog Ah, yeah, that sounds reasonable, what with -Q not giving it any elisp at all. I'm not sure about the mailing lists, but that is probably where we'd have to go if this doesn't lead anywhere.
@collares Interesting. I think that might have helped me figure this out! I source both the unstable channel and the overlay via tarbals. I made a change to how I did it after the native-comp branch was merged. Previously I did it like this:
unstable = import (
fetchTarball
"https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz"
) {
overlays = [
(
import (
builtins.fetchTarball {
url =
"https://github.com/nix-community/emacs-overlay/archive/master.tar.gz";
}
)
)
];
};And then used it as unstable.emacsGcc.
But then I changed the overlay to instead apply to nixpkgs (via nixpkgs.overlays) and the emacsGcc refererence to be pkgs.emacsGcc. After switching it back now, Emacs at least appears to be starting properly 🤞🏾 However, parts of my config still isn't applied and it's throwing all kinds of warnings in the Warnings buffer, plus a number of Lisp errors from external packages, such as this
Debugger entered--Lisp error: (void-variable LaTeX-fancyvrb-key-val-options-local)
LaTeX-fvextra-update-key-val()
TeX-auto-parse()
TeX-update-style()
TeX-auto-list-information("length")
LaTeX-length-list()
byte-code([...] // <- more content hereDid the jit compiler recently get stricter? Hmm.
So they were probably the result of the compiler recompiling everything. Interestingly enough, that also seems to have made Emacs correctly parse and apply my config to. Why would they have anything to do with each other? Perhaps if it gets a warning while compiling an external package it stops applying config to it?
thomasheartman
commented
3 years ago So after trying to make things work as expected for a bit, I have found the following: as a standalone X application, Emacs 28 (both emacsGit and emacsGcc) work just fine. However, when using EXWM, something goes wrong on initialization and any non-X buffers don't display and the mode line is missing. I can still interact with mini-buffer prompts (but only when using mini-frame and having them display in a separate frame). It seems that anything non-X related just doesn't work well. Using emacsUnstable, however, things appear to work as expected.
I don't know what would cause this, and it's probably a stretch asking for any input here, but if you have any ideas, I'd love to hear them. It seems weird that it would work with Emacs 27.2 and not 28. I also think I've seen some error messages when compiling emacsGcc about exwm-core not being available, but I wasn't able to reproduce this when I tried.
mbroeders
commented
3 years ago I'm experiencing the same problem and haven't found the solution yet. Though this may be the same issue as mentioned here on github.
collares
commented
3 years ago @thomasheartman @mbroeders There's an EXWM workaround at https://github.com/nix-community/emacs-overlay/issues/146#issuecomment-833916006. It's an upstream bug (which is very close to being fixed).
The void-variable error is probably a bug in the package you're using! Native compilation is stricter than the interpreter or byte-compiler at catching bugs involving files not requireing every other file being used. This is also the case with the warnings you see. I bet maintainers will fix those warnings very quickly once native compilation is on by default :)
thomasheartman
commented
3 years ago @mbroeders Oh, so it's not just me then? I'm happy that it's not just me messing up, but sad that it affects other people too.
@collares That's amazing! Thanks for the workaround. I'll try that out shortly to see if it makes things better. I followed the link to the mailing thread and the discourse about the issue. Is there a way to 'monitor' it, so that I know when it's fixed and when I can go back to using the unpatched version emacsGcc?
collares
commented
3 years ago @thomasheartman Unfortunately the "subscribe to a bug" feature does not work on GNU's debbugs instance, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439. The only "push" way I know to get notifications is to subscribe to the bug-gnu-emacs mailing list. This "subscribes" to every emacs bug, in a sense, but you can add filters so only bugs you care about reach your Inbox. If that's too much, you can install the debbugs emacs package to make it quicker to check the bug periodically.
It's likely that the fix will touch the same code the issue-causing commit did, so you'll get a notification anyway when the patch fails to apply :)
thomasheartman
commented
3 years ago @collares Ah, okay. Thanks! I'll just leave it in for now, then, and maybe try and take it out at some point in the future. Worst case, I can always put it back in :smile:
Anyway: the problem that the issue was created for has been solved: the solution was to apply the emacs overlay to the unstable channel and not to the stable channel. As such, I'll close this issue now. Thanks, everyone, for your help and participation! :pray:
thomasheartman
commented
3 years ago Just a heads up for anyone visiting this thread later: this was fixed some time around May 20th (2021) 🎉
As predicted, the patch referenced above stopped applying cleanly when it was fixed.
I have an issue that's similar to #147, but seems to be separate. Since Friday, when the build has succeeded, I get compilation errors on startup saying that
Because no-one else has reported this, I'm assuming it's something I'm doing wrong (in my config) but I don't know exactly what and I can't figure it out. As a result of this, Emacs doesn't load the init file and my setup doesn't work correctly. However, I can't quite figure out what the error is pointing to and think it might have some relation to this overlay.
I appreciate that it might not be directly related to this overlay, but it suddenly started happening just a few days ago and I don't know where else to turn. Thanks for your time and insights. :pray:
Additional info
Because this isn't clear from the issue, I want to point out that neither
emacsUnstablenoremacsGitshow the same errors on startup. I suppose this is to be expected because they don't use native compilation, but I wanted to be explicit about it.Also, my system is NixOS and the channel is
nixos-unstable