Package Details: emacs-gcc-wayland-devel-bin 28.1.50.151702-1

Git Clone URL: https://aur.archlinux.org/emacs-gcc-wayland-devel-bin.git (read-only, click to copy)
Package Base: emacs-gcc-wayland-devel-bin
Description: GNU Emacs. Development native-comp branch and pgtk branch combined, served as a binary.
Upstream URL: https://github.com/mpsq/emacs-gcc-wayland-devel-builder
Keywords: emacs
Licenses: GPL3
Conflicts: emacs, emacs-27-git, emacs-git, emacs-seq, emacs26-git
Provides: emacs, emacs-seq
Replaces: emacs-git, emacs-seq, emacs26-git, emacs27-git
Submitter: mpsq
Maintainer: mpsq
Last Packager: mpsq
Votes: 30
Popularity: 1.86
First Submitted: 2020-12-03 15:47 (UTC)
Last Updated: 2022-05-17 23:40 (UTC)

Latest Comments

mpsq commented on 2022-03-03 10:26 (UTC)

@CYS Great idea, thanks! I just added your modification.

CYS commented on 2022-03-03 04:21 (UTC)

I found the filename of the downloaded tarball is something like 28.**.tar.gz, which is hard to determine which package it belongs to.

As quoted from Arch wiki:

The downloaded source filename must be unique because the SRCDEST directory can be the same for all packages. For instance, using the version number of the project as a filename potentially conflicts with other projects with the same version number. In this case, the alternative unique filename to be used is provided with the syntax source=('unique_package_name::file_uri'); e.g. source=("$pkgname-$pkgver.tar.gz::https://github.com/coder/program/archive/v$pkgver.tar.gz").

I would suggest:

diff --git a/PKGBUILD b/PKGBUILD
index 504c84c..1ff91c4 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -14,7 +14,7 @@ provides=('emacs' 'emacs-seq')
 conflicts=('emacs' 'emacs26-git' 'emacs-27-git' 'emacs-git' 'emacs-seq')
 replaces=('emacs26-git' 'emacs27-git' 'emacs-git' 'emacs-seq')

-source=("https://github.com/mpsq/emacs-gcc-wayland-devel-builder/releases/download/$pkgver/$pkgver.tar.gz")
+source=("$pkgname-$pkgver.tar.gz::https://github.com/mpsq/emacs-gcc-wayland-devel-builder/releases/download/$pkgver/$pkgver.tar.gz")
 sha512sums=("94775d04d6e6b35e814156baa0f9da946d63b240c0f9cbf28ae608a4cd4182e36cc03f658555d936ffa38ced9fd28691124f8a4dd72c1f443c1f6f23039133d5")

 package() {

declanqian commented on 2021-12-26 08:55 (UTC)

Confirmed, it works. Thanks :+1 @vhoss-aur

vhoss-aur commented on 2021-12-26 08:17 (UTC)

There is a pull request for emacs-libvterm that should fix the issue mentioned by @declanqian.

Helpful comment in relevant github issue: https://github.com/akermu/emacs-libvterm/issues/559#issuecomment-997473811

Relevant pull request: https://github.com/akermu/emacs-libvterm/pull/562

declanqian commented on 2021-12-17 09:49 (UTC)

vterm refuse to build against the this latest version(emacs-gcc-wayland-devel-bin 28.0.90.151420-1)

Fatal error 11: Segmentation fault
Backtrace:
/usr/bin/emacs(emacs_backtrace+0xff)[0x56036c7cecff]
/usr/bin/emacs(terminate_due_to_signal+0x79)[0x56036c69e328]
/usr/bin/emacs(+0x1ab95a)[0x56036c7ce95a]
/usr/lib/libpthread.so.0(+0x13870)[0x7f2eb9ae9870]
/home/declan/.config/emacs/var/straight/build-28.0.90/vterm/vterm-modu
/usr/bin/emacs(Fmodule_load+0x7b6)[0x56036c8ad6b6]
/usr/bin/emacs(Fload+0x1195)[0x56036c89fac5]
/usr/bin/emacs(save_match_data_load+0x76)[0x56036c8a8726]
/usr/bin/emacs(Frequire+0x447)[0x56036c880c37]
/usr/bin/emacs(funcall_subr+0x110)[0x56036c866880]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(exec_byte_code+0x96e)[0x56036c8c7e4e]
/usr/bin/emacs(eval_sub+0x9ad)[0x56036c86813d]
/usr/bin/emacs(+0x27f18b)[0x56036c8a218b]
/usr/bin/emacs(Fload+0x10bd)[0x56036c89f9ed]
/usr/bin/emacs(save_match_data_load+0x76)[0x56036c8a8726]
/usr/bin/emacs(Fautoload_do_load+0x268)[0x56036c867388]
/usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emac
cafc76]
/usr/bin/emacs(funcall_subr+0xe7)[0x56036c866857]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emac
d_command_0+0x19e)[0x7f2eafcaf5be]
/usr/bin/emacs(funcall_subr+0x110)[0x56036c866880]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(Ffuncall_interactively+0xda)[0x56036c86194a]
/usr/bin/emacs(funcall_subr+0xcc)[0x56036c86683c]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(Fapply+0x43f)[0x56036c865a1f]
/usr/bin/emacs(Fcall_interactively+0x5af)[0x56036c861fef]
/usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emac
cafd61]
/usr/bin/emacs(funcall_subr+0xe7)[0x56036c866857]
/usr/bin/emacs(Ffuncall+0x4cc)[0x56036c86557c]
/usr/bin/emacs(+0x1818b3)[0x56036c7a48b3]
/usr/bin/emacs(internal_condition_case+0x11d)[0x56036c86c05d]
/usr/bin/emacs(command_loop_2+0x2e)[0x56036c7a39de]
/usr/bin/emacs(internal_catch+0x120)[0x56036c86b310]
/usr/bin/emacs(+0x18098c)[0x56036c7a398c]
/usr/bin/emacs(recursive_edit_1+0x7e)[0x56036c7a378e]
/usr/bin/emacs(Frecursive_edit+0x180)[0x56036c7b68e0]
/usr/bin/emacs(+0x17e121)[0x56036c7a1121]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7f2eb7b57b25]
/usr/bin/emacs(_start+0x2e)[0x56036c69f1ae]
...
Segmentation fault (core dumped)

Here are backtrace from gdb

#0  0x00007fffd6ecdc7a in emacs_module_init (ert=<optimized out>)
    at /home/declan/.config/emacs/var/straight/build-28.0.90/vterm/vterm-module.c:1404
#1  0x00005555557de6b6 in Fmodule_load ()
#2  0x00005555557d0ac5 in Fload ()
#3  0x00005555557d9726 in save_match_data_load ()
#4  0x00005555557b1c37 in Frequire ()
#5  0x0000555555797880 in funcall_subr ()
#6  0x000055555579657c in Ffuncall ()
#7  0x00005555557f8e4e in exec_byte_code ()
#8  0x000055555579913d in eval_sub ()
#9  0x000055555579e101 in Feval ()
#10 0x00007fffd6ee1b7a in top_level_run ()
    at /home/declan/.config/emacs/eln-cache/28.0.90-15314d31/vterm-a307bbd5-55c982d4.eln
#11 0x000055555580942f in load_comp_unit ()
#12 0x000055555580a17b in Fnative_elisp_load ()
#13 0x00005555557d0b1c in Fload ()
#14 0x00005555557d9726 in save_match_data_load ()
#15 0x0000555555798388 in Fautoload_do_load ()
#16 0x00007fffe6979c76 in F636f6d6d616e642d65786563757465_command_execute_0 ()
    at /usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.90/native-lisp/28.0.90-15314d31/preloaded/simple-fab5b0cf-24f63bd9.eln
#17 0x0000555555797857 in funcall_subr ()
#18 0x000055555579657c in Ffuncall ()
#19 0x00007fffe69795be in F657865637574652d657874656e6465642d636f6d6d616e64_execute_extended_command_0 ()
    at /usr/lib/emacs/28.0.90/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.90/native-lisp/28.0.90-15314d31/preloaded/simple-fab5b0cf-24f63bd9.eln
#20 0x0000555555797880 in funcall_subr ()
#21 0x000055555579657c in Ffuncall ()
#22 0x000055555579294a in Ffuncall_interactively ()
#23 0x000055555579783c in funcall_subr ()

mpsq commented on 2021-08-22 11:23 (UTC)

@ironborn emacs-git is, by definition, master. This package is based on the branch pgtk (rebased frequently from master), so differences are expected.

This package is vanilla Emacs, straight from the upstream branch. We do not patch it, we do not amend anything. If you find an issue, please use M-x report-emacs-bug.

That being said, considering how popular this package is, and how common your bug seems to be, I would be inclined to think that the issue is within your config.

ironborn commented on 2021-08-19 08:41 (UTC)

My hyper key definitions under wayland/sway aren't working with this package. For example, keybinding "H-o" interpreted as "o". emacs-git works fine with the same config and environment.

Crandel commented on 2021-06-30 09:03 (UTC)

Hi @mpsq, with the latest update everything works fine, thank you!

mpsq commented on 2021-06-28 10:10 (UTC)

@crashandburn4, @Crandel, @ees and @mklsls

This bug should now be fixed in latest release (28.0.50.149085), cf. commit https://github.com/flatwhatson/emacs/commit/a4fb5811fab64b7437fa47239d5aae39ba3ed82a. Let me know if it works :).

Extra details available at: https://debbugs.gnu.org/db/49/49118.html

crashandburn4 commented on 2021-06-23 11:10 (UTC)

Hi, I'm also having the same issues:

Compiling /usr/share/emacs/28.0.50/lisp/net/dbus.el...
/usr/share/emacs/28.0.50/lisp/net/dbus.el: Error: File error Opening output file

It can be worked around by messing with the directory perms in /usr/share/emacs/28.0.50/lisp or messing with users/groups, but is this the intended solution? from reading emacs-git and your comment, it sounds like it should be fixed?

Crandel commented on 2021-06-19 22:48 (UTC)

Hi @mpsq. I removed package, removed all caches, including native-comp cache and install it again but still have this errors every time I start emacs

ees commented on 2021-06-19 19:59 (UTC)

TLDR: it works!

I thought I tried that this morning and to my surprise it didn't work. Switched to emacs-git and IIRC it didn't work either initially, but after another uninstall/reinstall it worked. Now I'm back on emacs-gcc-wayland-devel-bin and it works too. Soo not sure what that was... I probably just did something dumb, but thought I'd mention it in case it's a real thing that others will hit too.

mpsq commented on 2021-06-19 19:39 (UTC)

Thanks for the link ees. It seems to be an issue with upstream and it looks like it was fixed already with https://github.com/emacs-mirror/emacs/commit/663fb3b774887d3d15a6791c3f35af56daa3c676. The latest version of this package should have the fix too, removing / installing emacs-gcc-wayland-devel-bin should be enough to fix the problem. Can you confirm that it is the case?

ees commented on 2021-06-19 14:28 (UTC) (edited on 2021-06-19 15:11 (UTC) by ees)

I'm seeing the same issue as @Crandel. Also seeing it with https://aur.archlinux.org/packages/emacs-git/; there's some relevant discussion over there.

Crandel commented on 2021-06-15 15:38 (UTC)

Every time I start emacs I got a lot of errors in Async-native-compile-log buffer like this

Compiling /usr/share/emacs/28.0.50/lisp/emacs-lisp/pcase.el...
/usr/share/emacs/28.0.50/lisp/emacs-lisp/pcase.el: Error: File error Opening output file
Compiling /usr/share/emacs/28.0.50/lisp/wid-edit.el...
/usr/share/emacs/28.0.50/lisp/wid-edit.el: Error: File error Opening output file

All these files exists and readable.

mpsq commented on 2021-06-01 08:26 (UTC) (edited on 2021-06-01 08:26 (UTC) by mpsq)

Did you also install libgccjit? You will need the version 11, it is a mandatory dependency to this package.

Also, please do not flag this package as out-of-date if it is actually not the case.

mklsls commented on 2021-05-31 21:17 (UTC) (edited on 2021-05-31 21:17 (UTC) by mklsls)

There is a problem with this package in Manjaro

emacs: /usr/lib/libgccjit.so.0: version `LIBGCCJIT_ABI_14' not found (required by emacs)

mpsq commented on 2021-03-02 18:26 (UTC) (edited on 2021-03-05 15:21 (UTC) by mpsq)

Hey guys, Emacs upstream was updated recently (compilation flags) and I just reflected the changes in this binary. If you had issues with doom-emacs (doom upgrade), or native-comp in general, this is now fixed.

jeslie0 commented on 2021-02-12 18:13 (UTC) (edited on 2021-06-15 16:57 (UTC) by jeslie0)

@mpsq I think I am having strange upscaling issues from using a 4k monitor. There is an open issue thread about it here: https://github.com/masm11/emacs/issues/90

EDIT: This issue has been resolved.

mpsq commented on 2021-02-12 15:48 (UTC)

@jeslie0 This is very stange, I open svg files on a daily basis and never had this issue. Is there anything special with your Emacs setup? Does it happen for all svgs? Are you zoomed-in?

jeslie0 commented on 2021-02-07 20:18 (UTC)

I'm having an issue where .svg files are blurry when viewed from inside Emacs (using "emacs -Q" also). It looks like an instance of the bug described here: https://emacs.stackexchange.com/questions/55305/svg-image-display-blurry

Is this a known bug or is it affecting anyone else?

equalis3r commented on 2020-12-23 09:35 (UTC)

Thank you for maintaining this packages. I installed emacs fresh from this package to solve the blurry problem with xwayland. So far, everything works perfectly.

bienjensu commented on 2020-12-22 14:50 (UTC)

@mpsq I can confirm that rolling back to 6d6b07b793f2c7d993fe238f99a63c4644dd44ed fixed the problem. Thanks for the help!

mpsq commented on 2020-12-22 14:32 (UTC) (edited on 2020-12-22 14:33 (UTC) by mpsq)

@bienjensu Fair enough, I tried and I can reproduce the issue.

I checked and this is a problem with Emacs itself, if you try the last version (of this pkg) everything is ok. The regression is from upstream and there is not much I can do to fix it. You should be able to roll-back to the last version though.

I might add additional checks in my building script, make sure that Emacs starts without warnings/errors before pushing a new version.

bienjensu commented on 2020-12-22 14:07 (UTC)

@mpsq Hello, yes I'm running without any config at all right now in order to diagnose problems.

mpsq commented on 2020-12-22 13:56 (UTC)

Hi Edward, I am not sure what the issue is from the top of my head. Maybe we can "work backwards": did you try to run vanilla Emacs? (without your personal config)

The error you are facing seems to be related to https://github.com/jwiegley/emacs-async. Are you using this as part of your Emacs config by any chance?

bienjensu commented on 2020-12-22 13:31 (UTC)

Hi, I'm getting errors with this. Everything is left at default in the PKGBUILD, my pkgmake.conf only changes -j and march=native on MAKEFLAGS. These errors repeat every time that after emacs is launched something starts native compilation (following the startpage link to the tutorial, for instance). *Warnings*:

Warning (comp): Debugger entered--Lisp error: (file-error "Opening output file" "Cannot overwrite file" "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el...") Disable showing Disable logging

*Async-native-compile-log*:

Debugger entered--Lisp error: (file-error "Opening output file" "Cannot overwrite file" "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el...")
signal(file-error ("Opening output file" "Cannot overwrite file" "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el..."))
byte-compile-file("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
#f(compiled-function (filename) "Byte-compile FILENAME spilling data from the byte compiler." #<bytecode 0x15639fb902450803>)("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
apply(#f(compiled-function (filename) "Byte-compile FILENAME spilling data from the byte compiler." #<bytecode 0x15639fb902450803>) "/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el" nil)
comp-spill-lap-function("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
comp-spill-lap("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el")
#f(compiled-function (pass) #<bytecode 0x8df95ff29d600bb>)(comp-spill-lap)
mapc(#f(compiled-function (pass) #<bytecode 0x8df95ff29d600bb>) (comp-spill-lap comp-limplify comp-fwprop comp-call-optim comp-ipa-pure comp-cond-cstr comp-fwprop comp-dead-code comp-tco comp-fwprop comp-remove-type-hints comp-final))
comp--native-compile("/usr/share/emacs/28.0.50/lisp/emacs-lisp/cl-lib.el" t)
eval-buffer(#<buffer  *load*> nil "/tmp/emacs-async-comp-cl-lib-OWDUvK.el" nil t)  ; Reading at buffer position 1385
load-with-code-conversion("/tmp/emacs-async-comp-cl-lib-OWDUvK.el" "/tmp/emacs-async-comp-cl-lib-OWDUvK.el" nil t)
command-line-1(("-l" "/tmp/emacs-async-comp-cl-lib-OWDUvK.el"))
command-line()
normal-top-level()

These repeat for all files emacs is attempting to native comp. I've already tried completely clearing out all configuration files, purging my /usr/lib/emacs and /usr/share/emacs, and reinstalling to no avail.