Emacs 29.3; suspicious error message from compile command in Emacs 29.3
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Emacs 29.3; suspicious error message from compile command in Emacs 29.3
The following error message appears in the terminal from which emacs was started every time I use the 'compile' command:
> emacs: writing to child signal FD: Invalid argument
The compilation itself (via make) works perfectly fine. Only this new message is a bit annoying. And so cryptic, isn't it? It did not appear up until the latest update.
This error message (or whatever it is) appears also, when I start emacs from a non-X tty (Ctrl + Alt + F2) and with '-Q' option. To be precise, it appears when I use 'M-x compile' and for longer compilation processes it appears at the end of the compilation, not at the beginning.
I asked for help with that at the GNU bugtracker and got the following answer:
> On 4/22/24 21:40, Eli Zaretskii wrote:
>> When a sub-process exits, Emacs writes to file descriptor which it
>> monitors with pselect. This is so we don't miss SIGCHLD for some
>> reason. Why in your case this write errors out with EINVAL, I don't
>> know. Perhaps Paul (CC'ed) could have some ideas.
>>
>> If this could happen for benign reasons, maybe we should silently
>> ignore these errors.
And then:
Please do report to them (slackware), it cannot possibly do any harm. When you
do, please ask them to tell us here whether this could be caused by
some downstream change they made in Emacs, or by some of the libraries
you have installed.
My question here: Gets anyone the same message when using the M-x compile command in Emacs 29.3 on slackware? And if so, where is the correct place for filing a bug report?
The following error message appears in the terminal from which emacs was started every time I use the 'compile' command:
> emacs: writing to child signal FD: Invalid argument
I've seen that, I believe it's related to the stock Slackware build script. Build Emacs yourself according to the SlackBuilds in post #4 here (no native-comp) or #18 here (with native-comp, requires rebuilding gcc) and the issue should be gone.
It is the first one, the patch that came to my attention last week.
Recompile as above, and problem solved I can confirm from testing (with `emacs -nw -Q`) that stock Emacs 29.3 produces the "write to child signal FD: Bad file descriptor" error after M-x compile, whereas the recompiled ones do not.
In sum, this error seems to be some quirk in how Emacs is being built on Slackware.
I've seen that, I believe it's related to the stock Slackware build script. Build Emacs yourself according to the SlackBuilds in post #4 here (no native-comp) or #18 here (with native-comp, requires rebuilding gcc) and the issue should be gone.
Thank you, I'd like to try that. Downloaded the source from https://packages.slackware.com/ and tried to verify the gpg signature of the tarball and gpg said
> gpg: Can't check signature: public key not found
Searched slackware.com but couldn't find the key. Where can I get it?
And then: What does 'native-comp' mean? Is it only the terminal version of emacs invoced with -nw, or does it more than that? I'd like to have it, but it is not essential.
I do not understand why an emacs with more functionality (X window etc.) can be build with the gcc from the distro and apperently the part with less functionality requires another version of gcc.
Is there a simple explanation for that?
I once installed the multilib thing from alienbob on my system and it works well. And there was some recompiling for the mingw that is also on my system. Everything works well, but I've forgotten how everything is interrelated and I don't want to endanger things. Maybe I should stick with my alias emacs=emacs 2>/dev/null "solution" for now.
Yes. In a word, developers. Each dev compiles code, and it usually works on present versions of gcc, but not necessarily on future ones.
By all means stick with your alias and get used to the fact that things that work might bellyache like mad because the developers like that feedback. It helps them find faults. If you think emacs is bad, wait until you start wine from a terminal!
Thank you, I'd like to try that. Downloaded the source from https://packages.slackware.com/ and tried to verify the gpg signature of the tarball and gpg said
> gpg: Can't check signature: public key not found
Searched slackware.com but couldn't find the key. Where can I get it?
You need the key for the person who signed the release archive for Emacs (nothing to do with Slackware):
Code:
gpg2 --verify emacs-29.3.tar.xz.sig
[...]
gpg: Good signature from "Eli Zaretskii <eliz@gnu.org>" [unknown]
Quote:
Originally Posted by 3Tom
And then: What does 'native-comp' mean? Is it only the terminal version of emacs invoced with -nw, or does it more than that? I'd like to have it, but it is not essential.
It can lead to faster Emacs in some aspects, but just search it up and decide if you want it or not.
Quote:
Originally Posted by 3Tom
I do not understand why an emacs with more functionality (X window etc.) can be build with the gcc from the distro and apperently the part with less functionality requires another version of gcc.
I don't know what you mean, if you want the native-comp feature on Slackware you will need to recompile gcc, but you can also just ignore it. Both build scripts above will give a GUI and terminal version of Emacs.
Quote:
Originally Posted by 3Tom
Maybe I should stick with my alias emacs=emacs 2>/dev/null "solution" for now.
You can quite easily build Emacs with the build script here, no native-comp/gcc messing around, and the problem will be fixed properly.
Yes. In a word, developers. Each dev compiles code, and it usually works on present versions of gcc, but not necessarily on future ones.
By all means stick with your alias and get used to the fact that things that work might bellyache like mad because the developers like that feedback. It helps them find faults. If you think emacs is bad, wait until you start wine from a terminal!
Thanks for this enlightening meta-persepctive!
Finally I found the key (is is on savannah.org what makes sense..) but decided to stick with the alias.
Tue Apr 23 19:48:05 UTC 2024
patches/packages/emacs-29.3-x86_64-2_slack15.0.txz: Rebuilt.
This is a bugfix release.
Only build the X11/GTK+3 version. Use "emacs -nw" if you want to start it
in a terminal emulator in text mode, or rebuild if you really need to get
rid of the X11 dependency for some reason.
Build using --with-pdumper=auto. It seems that --with-dumping=unexec produces
a buggy Emacs here in the modern era, with symptoms such as "child signal FD:
Invalid argument". It's possible this had something to do with the reported
memory leaks as well.
Thanks to 3Tom for the bug report.
Tue Apr 23 19:48:05 UTC 2024
patches/packages/emacs-29.3-x86_64-2_slack15.0.txz: Rebuilt.
This is a bugfix release.
Only build the X11/GTK+3 version. Use "emacs -nw" if you want to start it
in a terminal emulator in text mode, or rebuild if you really need to get
rid of the X11 dependency for some reason.
Build using --with-pdumper=auto. It seems that --with-dumping=unexec produces
a buggy Emacs here in the modern era, with symptoms such as "child signal FD:
Invalid argument". It's possible this had something to do with the reported
memory leaks as well.
Thanks to 3Tom for the bug report.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.