This is the mail archive of the
mailing list for the Cygwin project.
Re: [64bit] Problem with emacs and shared memory under X11
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 19 Jul 2013 13:35:09 +0200
- Subject: Re: [64bit] Problem with emacs and shared memory under X11
- References: <51D803A0 dot 7090700 at cornell dot edu> <51D82992 dot 5010402 at dronecode dot org dot uk> <51E70D37 dot 5020600 at dronecode dot org dot uk> <20130718083748 dot GA9628 at calimero dot vinschen dot de> <51E858E2 dot 7050802 at dronecode dot org dot uk> <20130718213455 dot GC30542 at calimero dot vinschen dot de> <51E91378 dot 6060402 at dronecode dot org dot uk>
- Reply-to: cygwin-apps at cygwin dot com
On Jul 19 11:22, Jon TURNEY wrote:
> On 18/07/2013 22:34, Corinna Vinschen wrote:
> > On Jul 18 22:06, Jon TURNEY wrote:
> >> On 18/07/2013 09:37, Corinna Vinschen wrote:
> >>> On Jul 17 22:31, Jon TURNEY wrote:
> >>>> After going around in circles on this a few times, this is what I now think I
> >>>> know:
> >>>> The proximate cause of this error is that the x86_64 libcairo2 package appears
> >>>> to be built with IPC_RMID_DEFERRED_RELEASE defined, which should only happen
> >>>> on systems which allow processes to shmat() to a shared memory segment which
> >>>> has already been marked for deletion with shmctl(IPC_RMID) (A non-portable
> >>>> Linux behaviour)
> >>>> (This behaviour can be turned on in cygwin by setting the
> >>>> 'kern.ipc.shm_allow_removed' to 'yes' in /etc/cygserver.conf, so that is also
> >>>> a work around)
> >>>> Attached is the configure test extracted from cairo, which for some reason
> >>>> functions incorrectly on x86_64.
> >>> I'm glad to read it's not a bug in Cygwin or Cygserver :}
> >> I'm a bit confused to read that you don't consider this shmtest.c behaving
> >> incorrectly on x86_64 a bug in Cygwin.
> > I totally misunderstood your mail apparently. Your mail implied to me
> > that this is a build error in libcairo2, not in Cygwin, so I thought
> > Cygwin is off the hook.
> Sorry, I should have explained more clearly that a SHM bug in cygwin could
> cause an incorrect result for a configure test in cairo, which causes cairo to
> be built wrongly, which causes applications which use it to fail with SHM errors.
No worries, after you clarified, pieces fell into place :)
> > Thanks for tracking this down and the patch. I'm just wondering. This
> > is one of those subtil bugs introduced by the size difference between
> > int and pointers. Maybe we should better provide a constructor which
> > takes an ssize_t as input, rather than an int. Does the below fix the
> > problem as well?
> Oh yes, that works, and is a bit clearer.
Thanks for testing. I applied the patch and attributed it to you in
the ChangeLog since you did all the work anyway.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com