I see Emacs is not more starting. It may be related to recent updates of some libraries and just needs to rebuild it. Or it may be some more serious problem.
Quick check on 64bit R1B5 seems to be OK? Maybe nightly related?
Works fine for me on 64 bit nightly.
I run Haiku nightly.
I updated Haiku, reinstalled Emacs, no changes. I am sure it worked previously, I tried to use it with CLISP. But if it works, as last resort I can reinstall Haiku.
There are no error messages if you start Emacs from a Terminal? and no error message in the Emacs message buffers?
Also, does Emacs -Q start up properly?
Emacs from Terminal does not start, it blocks with no errors or logs. Emacs -Q is the same, no application startup, no errors / logs in Teminal.
The only thing I can think to check is if there are messages in /var/log/syslog that give some information.
If you find nothing on the syslog… maybe try strace emacs and see if you can find something wrong there? (can be hard to know what to look for, but it helped me find the source of weird errors more than once).
Strange: I reinstalled Haiku and installed FilWip (probably, irrelevant), CLISP and Emacs. And Emacs does not start. Maybe it conflicts with some of these packages or their dependencies?
P.S. I also take a look at strace /bin/emacs-29.3 and strace /boot/system/apps/Emacs and did not see any obvious problems.
So with R1B5 I get this from strace:
[ 485] open(0xffffffff, "/boot/system/settings/network/hostname", 0, 0x0) = 0x5 (753 us)
[ 485] read(0x5, 0xffffffffffffffff, 0x7f1c49f65050, 0x1f) = 0x6 (516 us)
[ 485] close(0x5) = 0x0 No error (442 us)
[ 485] set_signal_mask(0x3, 0x7f1c49f64fa8, [0x7f1c49f64fd0]) = 0x0 No error (607 us)
[ 485] create_pipe() = 0x0 No error ([0x5, 0x6]) (419 us)
but with nightly, it hangs just after the set_signal_mask, so I guess it might have something to do with kernel/libroot: add pipe2() from POSIX.1-2024
I built Emacs 30 on R1/beta5 not more than two months ago. How are you building Emacs? It ought to work if you compile the latest pretest from source.
I am using Emacs from HaikuDepot. Never built it myself.
So the issue here is that the change in src/system/libroot/posix/unistd/pipe.c now implements pipe by calling pipe2. Usually, this should be fine, except that emacs tries to emulate pipe2 if it’s not available (which was the case for R1B5), so that pipe2 calls pipe (in libroot) which in turn calls pipe2 from emacs.
2 Likes
TRT is to email this information to bug-gnulib@gnu.org. I’d be surprised if other GNU software wasn’t affected.
Also if these symbols were versioned, there’d be no difficulty at all.
2 Likes
It’s fixed in Haiku now, pipe really shouldn’t be calling a pipe2 (when it can potentially be replaced by a user program).
I don’t think gnulib could realistically do something else here.
1 Like
On Android (which never versions new symbols) Gnulib prefers to prefix its replacement symbols with “rpl_”. Likewise if Haiku doesn’t version its new symbols, the same treatment would be more appropriate than the status quo.
1 Like
I was waiting for update of Emacs package, but realized the update of Haiku solves this issue. Confirm Emacs starts again. Thank you all involved.