[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs on QNX
From: |
Paul Eggert |
Subject: |
Re: Emacs on QNX |
Date: |
Sun, 22 Oct 2017 21:51:07 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
Thanks for looking into a QNX port.
Elad Lahav wrote:
There is still a stub that returns -1 and sets errno to
ENOMEM, but the Emacs code doesn't check for that, and interprets the
result as the address 0xffffffffffffffff.
Which part of the Emacs code is that? Is this the call in src/unexelf.c? If so,
I can fix that.
To overcome the problem, I wrote a naive implementation of sbrk() in a
dynamically-linked library
Although that's clever, I'm hoping that we can port to QNX the same way we port
to Cygwin, as Cygwin already uses a fake sbrk. (Eventually Emacs has got to stop
using sbrk, but we don't have an adequate solution to that bigger problem yet.)
Does the attached patch work for you instead?
+ CFLAGS="$CFLAGS -D__NO_EXT_QNX"
Could you fill us on on what __NO_EXT_QNX does? The symbol I see mentioned in
public discussions is _QNX_SOURCE. What is the difference between those two
symbols, and why is __NO_EXT_QNX preferable here? What happens if you leave it out?
qnx.diff
Description: Text Data
- Emacs on QNX, Elad Lahav, 2017/10/22
- Re: Emacs on QNX,
Paul Eggert <=