Re: Is the Cygw32 port ready for testing?

Re: Is the Cygw32 port ready for testing?

[Angelo Graziosi]

Ken Brown wrote:

> It builds for me now.

It fails for me... (trunk rev. 110588):

[...]
checking whether localtime_r is compatible with its POSIX signature... yes
checking for library containing timer_settime... none required
checking for timer_settime... yes

Configured for `i686-pc-cygwin'.

   Where should the build process find the source code? 
/home/angelo/work/emacs
   What compiler should emacs be built with?               gcc 
-std=gnu99 -O3
   Should Emacs use the GNU version of malloc?             yes
   Should Emacs use a relocating allocator for buffers?    no
   Should Emacs use mmap(2) for buffer allocation?         yes
   What window system should Emacs use?                    w32
   What toolkit should Emacs use?                          none
   Where do we find X Windows header files?                Standard dirs
   Where do we find X Windows libraries?                   Standard dirs
   Does Emacs use -lXaw3d?                                 no
   Does Emacs use -lXpm?                                   yes
   Does Emacs use -ljpeg?                                  yes
   Does Emacs use -ltiff?                                  yes
   Does Emacs use a gif library?                           yes -lgif
   Does Emacs use -lpng?                                   yes
   Does Emacs use -lrsvg-2?                                no
   Does Emacs use imagemagick?                             no
   Does Emacs use -lgpm?                                   no
   Does Emacs use -ldbus?                                  yes
   Does Emacs use -lgconf?                                 no
   Does Emacs use GSettings?                               no
   Does Emacs use -lselinux?                               no
   Does Emacs use -lgnutls?                                yes
   Does Emacs use -lxml2?                                  yes
   Does Emacs use -lfreetype?                              no
   Does Emacs use -lm17n-flt?                              no
   Does Emacs use -lotf?                                   no
   Does Emacs use -lxft?                                   no
   Does Emacs use toolkit scroll bars?                     yes


checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
[...]
gcc -std=gnu99 -c -I/usr/include/noX -Demacs  -I. 
-I/home/angelo/work/emacs/src  -I../lib 
-I/home/angelo/work/emacs/src/../lib           -I/usr/include/libxml2 
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include          -MMD -MF 
deps/lastfile.d -MP   -I/usr/include/p11-kit-1      -O3 
/home/angelo/work/emacs/src/lastfile.c
In file included from /home/angelo/work/emacs/src/image.c:2964:0:
/usr/include/X11/xpm.h:70:63: fatal error: simx.h: No such file or directory
compilation terminated.
Makefile:325: recipe for target `image.o' failed
make[2]: *** [image.o] Error 1
make[2]: *** Attesa per i processi non terminati....
make[2]: uscita dalla directory "/home/angelo/work/emacs/Work/src"
Makefile:333: recipe for target `src' failed
make[1]: *** [src] Error 2
make[1]: uscita dalla directory "/home/angelo/work/emacs/Work"
Makefile:909: recipe for target `bootstrap' failed
make: *** [bootstrap] Error 2


Ciao,
   Angelo.

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/19/2012 12:03 PM, Angelo Graziosi wrote:
> It fails for me... (trunk rev. 110588):
>
> [...]
> In file included from /home/angelo/work/emacs/src/image.c:2964:0:
> /usr/include/X11/xpm.h:70:63: fatal error: simx.h: No such file or
> directory

You need to install libXpm-noX-devel to get simx.h.

Ken

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On 10/19/2012 7:42 PM, Ken Brown wrote:
> On 10/19/2012 12:03 PM, Angelo Graziosi wrote:
>> It fails for me... (trunk rev. 110588):
>>
>> [...]
>> In file included from /home/angelo/work/emacs/src/image.c:2964:0:
>> /usr/include/X11/xpm.h:70:63: fatal error: simx.h: No such file or
>> directory
> 
> You need to install libXpm-noX-devel to get simx.h.

I wonder how we can change the configuration test to catch this problem at
configure-time.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: Is the Cygw32 port ready for testing?

[Andreas Schwab]

Daniel Colascione <dancol@dancol.org> writes:

> On 10/19/2012 7:42 PM, Ken Brown wrote:
>> On 10/19/2012 12:03 PM, Angelo Graziosi wrote:
>>> It fails for me... (trunk rev. 110588):
>>>
>>> [...]
>>> In file included from /home/angelo/work/emacs/src/image.c:2964:0:
>>> /usr/include/X11/xpm.h:70:63: fatal error: simx.h: No such file or
>>> directory
>> 
>> You need to install libXpm-noX-devel to get simx.h.
>
> I wonder how we can change the configuration test to catch this problem at
> configure-time.

I don't think Emacs should check for every third party packaging bug.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Is the Cygw32 port ready for testing?

[Stephen J. Turnbull]

Andreas Schwab writes:

 > I don't think Emacs should check for every third party packaging bug.

Anybody who actually runs configure is a relatively high-probability
potential code contributor.  This is a rather cheap way to convince
such people that Emacs cares about them and their platform.

Re: Is the Cygw32 port ready for testing?

[Angelo Graziosi]

Il 20/10/2012 4.42, Ken Brown ha scritto:
> On 10/19/2012 12:03 PM, Angelo Graziosi wrote:
>> It fails for me... (trunk rev. 110588):
>>
>> [...]
>> In file included from /home/angelo/work/emacs/src/image.c:2964:0:
>> /usr/include/X11/xpm.h:70:63: fatal error: simx.h: No such file or
>> directory
>
> You need to install libXpm-noX-devel to get simx.h.

Now it builds and seems to work...

Obviously, it ignores :-( the ~/.Xdefaults file where I defined

Emacs.FontBackend:      xft
Emacs.font:             Bitstream Vera Sans Mono 11
Xft*antialias:          true
Xft*autohint:           true


Ciao,
  Angelo.

Re: Is the Cygw32 port ready for testing?

[Eli Zaretskii]

> Date: Sat, 20 Oct 2012 10:53:52 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Cc: emacs <emacs-devel@gnu.org>
> 
> Il 20/10/2012 4.42, Ken Brown ha scritto:
> > On 10/19/2012 12:03 PM, Angelo Graziosi wrote:
> >> It fails for me... (trunk rev. 110588):
> >>
> >> [...]
> >> In file included from /home/angelo/work/emacs/src/image.c:2964:0:
> >> /usr/include/X11/xpm.h:70:63: fatal error: simx.h: No such file or
> >> directory
> >
> > You need to install libXpm-noX-devel to get simx.h.
> 
> Now it builds and seems to work...
> 
> Obviously, it ignores :-( the ~/.Xdefaults file where I defined
> 
> Emacs.FontBackend:      xft
> Emacs.font:             Bitstream Vera Sans Mono 11
> Xft*antialias:          true
> Xft*autohint:           true

Obviously, since it doesn't use X at all, and thus its font backend is
Uniscribe, it cannot be xft.

You should still be able to use that font, by adding the customization
to yoyr .emacs or by putting it into Registry.  As for anti-aliasing,
it is controlled by a global Windows setting.

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/20/2012 4:53 AM, Angelo Graziosi wrote:
> Il 20/10/2012 4.42, Ken Brown ha scritto:
>> On 10/19/2012 12:03 PM, Angelo Graziosi wrote:
>>> It fails for me... (trunk rev. 110588):
>>>
>>> [...]
>>> In file included from /home/angelo/work/emacs/src/image.c:2964:0:
>>> /usr/include/X11/xpm.h:70:63: fatal error: simx.h: No such file or
>>> directory
>>
>> You need to install libXpm-noX-devel to get simx.h.
>
> Now it builds and seems to work...
>
> Obviously, it ignores :-( the ~/.Xdefaults file...

Right.  The Cygw32 build is for people who would rather use the native 
Windows GUI rather than X11.  People who want to use ~/.Xdefaults for 
customization should stick to the standard X11 build.  My only reason 
for testing the Cygw32 build is so that I could offer it as an 
alternative to emacs-X11 in the Cygwin distribution.

Ken

Is the Cygw32 port ready for testing?

[Ken Brown]

Daniel,

Are you able to build the Cygw32 port of emacs with the current trunk? 
I tried and got the following error:

image.o:image.c:(.data+0x100): undefined reference to `_init_tiff_functions'

The reason seems to be that the declaration of init_tiff_functions is 
conditioned on HAVE_NTGUI, but the definition of it is conditioned on 
WINDOWSNT.  I'm not sure what your intention is here, but maybe I'm just 
testing prematurely, and Cygw32 is not yet ready for testing.

Ken

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

On 10/14/2012 3:44 PM, Ken Brown wrote:
> Daniel,
> 
> Are you able to build the Cygw32 port of emacs with the current trunk? 

Yes, but I didn't have libtiff installed.

> I tried
> and got the following error:

Thanks for reporting the build break. I've updated the trunk. Revision 110548
should resolve the problem.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/14/2012 7:28 PM, Daniel Colascione wrote:
> Thanks for reporting the build break. I've updated the trunk. Revision 110548
> should resolve the problem.

Thanks.  The build now completes as long as I use the configure option 
--without-dbus.  Otherwise the build fails while compiling dbusbind.c:

gcc -std=gnu99 -c -I/usr/include/noX -Demacs  -I. 
-I/home/kbrown/src/emacs/test-w32/src  -I../lib 
-I/home/kbrown/src/emacs/test-w32/src/../lib 
-I/usr/include/libxml2   -I/usr/include/dbus-1.0 
-I/usr/lib/dbus-1.0/include          -MMD -MF deps/dbusbind.d -MP 
-I/usr/include/p11-kit-1      -g3 -O2 dbusbind.c
dbusbind.c: In function ‘Fdbus_message_internal’:
dbusbind.c:1263:25: error: expected ‘{’ before ‘=’ token
dbusbind.c:1263:15: error: two or more data types in declaration specifiers
dbusbind.c:1294:17: error: expected ‘{’ before ‘=’ token
dbusbind.c:1318:7: error: expected ‘{’ before ‘)’ token
dbusbind.c:1318:7: warning: type defaults to ‘int’ in type name
dbusbind.c:1318:7: error: expected ‘{’ before ‘)’ token
dbusbind.c:1318:7: warning: type defaults to ‘int’ in type name
dbusbind.c:1318:7: error: expected ‘{’ before ‘)’ token
dbusbind.c:1318:7: warning: type defaults to ‘int’ in type name
dbusbind.c:1331:7: error: expected expression before ‘struct’
dbusbind.c:1331:7: error: too few arguments to function ‘format2’
lisp.h:3120:20: note: declared here
dbusbind.c:1331:7: error: expected expression before ‘struct’
dbusbind.c:1331:7: error: too few arguments to function ‘format2’
lisp.h:3120:20: note: declared here
dbusbind.c:1341:7: error: expected expression before ‘struct’
dbusbind.c:1341:7: error: too few arguments to function ‘format2’
lisp.h:3120:20: note: declared here
dbusbind.c:1341:7: error: expected expression before ‘struct’
dbusbind.c:1341:7: error: too few arguments to function ‘format2’
lisp.h:3120:20: note: declared here
dbusbind.c:1412:47: error: expected ‘{’ before ‘)’ token
dbusbind.c:1412:47: warning: type defaults to ‘int’ in type name
dbusbind.c:1412:47: error: expected ‘{’ before ‘)’ token
dbusbind.c:1412:47: warning: type defaults to ‘int’ in type name
dbusbind.c: In function ‘xd_read_message_1’:
dbusbind.c:1530:30: error: expected identifier or ‘(’ before ‘struct’
dbusbind.c:1565:13: error: expected ‘{’ before ‘=’ token
dbusbind.c:1566:3: error: ‘member’ undeclared (first use in this function)
dbusbind.c:1566:3: note: each undeclared identifier is reported only 
once for each function it appears in
dbusbind.c:1568:3: error: expected expression before ‘struct’
dbusbind.c:1602:22: error: expected ‘{’ before ‘==’ token
dbusbind.c:1602:31: error: expected expression before ‘||’ token
dbusbind.c:1602:31: warning: type defaults to ‘int’ in type name
dbusbind.c:1609:25: error: expected expression before ‘struct’
dbusbind.c:1644:33: error: expected ‘{’ before ‘==’ token
dbusbind.c:1644:75: error: expected expression before ‘,’ token
dbusbind.c:1644:75: warning: type defaults to ‘int’ in type name

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/14/2012 9:16 PM, Ken Brown wrote:
> On 10/14/2012 7:28 PM, Daniel Colascione wrote:
>> Thanks for reporting the build break. I've updated the trunk. Revision
>> 110548
>> should resolve the problem.
>
> Thanks.  The build now completes as long as I use the configure option
> --without-dbus.  Otherwise the build fails while compiling dbusbind.c:
>
> gcc -std=gnu99 -c -I/usr/include/noX -Demacs  -I.
> -I/home/kbrown/src/emacs/test-w32/src  -I../lib
> -I/home/kbrown/src/emacs/test-w32/src/../lib -I/usr/include/libxml2
> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include          -MMD -MF
> deps/dbusbind.d -MP -I/usr/include/p11-kit-1      -g3 -O2 dbusbind.c
> dbusbind.c: In function ‘Fdbus_message_internal’:
> dbusbind.c:1263:25: error: expected ‘{’ before ‘=’ token
> dbusbind.c:1263:15: error: two or more data types in declaration specifiers
> dbusbind.c:1294:17: error: expected ‘{’ before ‘=’ token
> dbusbind.c:1318:7: error: expected ‘{’ before ‘)’ token
> dbusbind.c:1318:7: warning: type defaults to ‘int’ in type name
> dbusbind.c:1318:7: error: expected ‘{’ before ‘)’ token
> dbusbind.c:1318:7: warning: type defaults to ‘int’ in type name
> dbusbind.c:1318:7: error: expected ‘{’ before ‘)’ token
> dbusbind.c:1318:7: warning: type defaults to ‘int’ in type name
> dbusbind.c:1331:7: error: expected expression before ‘struct’
> dbusbind.c:1331:7: error: too few arguments to function ‘format2’
> lisp.h:3120:20: note: declared here
> dbusbind.c:1331:7: error: expected expression before ‘struct’
> dbusbind.c:1331:7: error: too few arguments to function ‘format2’
> lisp.h:3120:20: note: declared here
> dbusbind.c:1341:7: error: expected expression before ‘struct’
> dbusbind.c:1341:7: error: too few arguments to function ‘format2’
> lisp.h:3120:20: note: declared here
> dbusbind.c:1341:7: error: expected expression before ‘struct’
> dbusbind.c:1341:7: error: too few arguments to function ‘format2’
> lisp.h:3120:20: note: declared here
> dbusbind.c:1412:47: error: expected ‘{’ before ‘)’ token
> dbusbind.c:1412:47: warning: type defaults to ‘int’ in type name
> dbusbind.c:1412:47: error: expected ‘{’ before ‘)’ token
> dbusbind.c:1412:47: warning: type defaults to ‘int’ in type name
> dbusbind.c: In function ‘xd_read_message_1’:
> dbusbind.c:1530:30: error: expected identifier or ‘(’ before ‘struct’
> dbusbind.c:1565:13: error: expected ‘{’ before ‘=’ token
> dbusbind.c:1566:3: error: ‘member’ undeclared (first use in this function)
> dbusbind.c:1566:3: note: each undeclared identifier is reported only
> once for each function it appears in
> dbusbind.c:1568:3: error: expected expression before ‘struct’
> dbusbind.c:1602:22: error: expected ‘{’ before ‘==’ token
> dbusbind.c:1602:31: error: expected expression before ‘||’ token
> dbusbind.c:1602:31: warning: type defaults to ‘int’ in type name
> dbusbind.c:1609:25: error: expected expression before ‘struct’
> dbusbind.c:1644:33: error: expected ‘{’ before ‘==’ token
> dbusbind.c:1644:75: error: expected expression before ‘,’ token
> dbusbind.c:1644:75: warning: type defaults to ‘int’ in type name

Another thing I just noticed is that the executable depends on some of 
the X11 libraries, which I don't think is what you wanted:

$ cygcheck src/emacs.exe
[...]
   C:\cygwin\bin\cyggif-4.dll
     C:\cygwin\bin\cyggcc_s-1.dll
     C:\cygwin\bin\cygX11-6.dll
       C:\cygwin\bin\cygxcb-1.dll
         C:\cygwin\bin\cygXau-6.dll
         C:\cygwin\bin\cygXdmcp-6.dll
[...]

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On 10/14/2012 6:31 PM, Ken Brown wrote:
>   C:\cygwin\bin\cyggif-4.dll
>     C:\cygwin\bin\cyggcc_s-1.dll
>     C:\cygwin\bin\cygX11-6.dll
>       C:\cygwin\bin\cygxcb-1.dll
>         C:\cygwin\bin\cygXau-6.dll
>         C:\cygwin\bin\cygXdmcp-6.dll

That looks like a separate problem with Cygwin's libgif.  Ldd on cyggif-4.dll
itself reports the X11 dependency. I'd be happy requiring the X11 DLLs until we
fix the problem over in Cygwin. I'd also be happy compiling --without-gif: it's
up to you.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On 10/14/2012 6:16 PM, Ken Brown wrote:
> On 10/14/2012 7:28 PM, Daniel Colascione wrote:
>> Thanks for reporting the build break. I've updated the trunk. Revision 110548
>> should resolve the problem.
> 
> Thanks.  The build now completes as long as I use the configure option
> --without-dbus.  Otherwise the build fails while compiling dbusbind.c:

Thanks. The symbol "interface" is defined to something else by the platform
headers. The following trivial patch resolves the issue.  The alternative is to
replace the use of "interface" with some other symbol everywhere in the source
file; I'll write up a patch to do that if someone objects to this one.

=== modified file 'src/dbusbind.c'
--- src/dbusbind.c	2012-09-15 07:06:56 +0000
+++ src/dbusbind.c	2012-10-15 01:30:49 +0000
@@ -32,6 +32,10 @@
 #define DBUS_NUM_MESSAGE_TYPES 5
 #endif

+#ifdef interface
+#undef interface
+#endif
+
 \f
 /* Subroutines.  */
 static Lisp_Object Qdbus_init_bus;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Is the Cygw32 port ready for testing?

[Andreas Schwab]

Daniel Colascione <dancol@dancol.org> writes:

> === modified file 'src/dbusbind.c'
> --- src/dbusbind.c	2012-09-15 07:06:56 +0000
> +++ src/dbusbind.c	2012-10-15 01:30:49 +0000
> @@ -32,6 +32,10 @@
>  #define DBUS_NUM_MESSAGE_TYPES 5
>  #endif
>
> +#ifdef interface
> +#undef interface
> +#endif

There is no need for #ifdef, and of course it should be amended by a
comment.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On Sun, Oct 14, 2012 at 9:37 PM, Daniel Colascione <dancol@dancol.org> wrote:
> On 10/14/2012 6:16 PM, Ken Brown wrote:
>> On 10/14/2012 7:28 PM, Daniel Colascione wrote:
>>> Thanks for reporting the build break. I've updated the trunk. Revision 110548
>>> should resolve the problem.
>>
>> Thanks.  The build now completes as long as I use the configure option
>> --without-dbus.  Otherwise the build fails while compiling dbusbind.c:
>
> Thanks. The symbol "interface" is defined to something else by the platform
> headers. The following trivial patch resolves the issue.  The alternative is to
> replace the use of "interface" with some other symbol everywhere in the source
> file; I'll write up a patch to do that if someone objects to this one.
>
> === modified file 'src/dbusbind.c'
> --- src/dbusbind.c      2012-09-15 07:06:56 +0000
> +++ src/dbusbind.c      2012-10-15 01:30:49 +0000
> @@ -32,6 +32,10 @@
>  #define DBUS_NUM_MESSAGE_TYPES 5
>  #endif
>
> +#ifdef interface
> +#undef interface
> +#endif
> +
>
>  /* Subroutines.  */
>  static Lisp_Object Qdbus_init_bus;
>

The build with dbus support still doesn't work.  An "Emacs abort"
dialogue box comes up during the build [which I've never seen before
when doing a Cygwin build] asking if I want to attach gdb.  I'm on my
way out of town and don't have time to look at this any further.  I
did verify that the build --without-dbus still works.

Ken

Re: Is the Cygw32 port ready for testing?

[Eli Zaretskii]

> Date: Mon, 15 Oct 2012 10:14:26 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: Emacs <emacs-devel@gnu.org>
> 
> The build with dbus support still doesn't work.  An "Emacs abort"
> dialogue box comes up during the build [which I've never seen before
> when doing a Cygwin build] asking if I want to attach gdb.

That dialog is one sign that the native Windows GUI and window manager
are used for display and input.  It's what happens when Emacs aborts
itself or catches some other fatal signal.

Attaching a debugger, as instructed in the dialog, will allow you to
produce a backtrace that might show what went wrong.

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/15/2012 1:16 PM, Eli Zaretskii wrote:
>> Date: Mon, 15 Oct 2012 10:14:26 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> Cc: Emacs <emacs-devel@gnu.org>
>>
>> The build with dbus support still doesn't work.  An "Emacs abort"
>> dialogue box comes up during the build [which I've never seen before
>> when doing a Cygwin build] asking if I want to attach gdb.
>
> That dialog is one sign that the native Windows GUI and window manager
> are used for display and input.  It's what happens when Emacs aborts
> itself or catches some other fatal signal.
>
> Attaching a debugger, as instructed in the dialog, will allow you to
> produce a backtrace that might show what went wrong.

I'm hoping that Daniel will be able to reproduce the problem and fix it. 
  If not, I'll try to debug it when I return from my trip.

Ken

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On 10/15/2012 12:33 PM, Ken Brown wrote:
> On 10/15/2012 1:16 PM, Eli Zaretskii wrote:
>>> Date: Mon, 15 Oct 2012 10:14:26 -0400
>>> From: Ken Brown <kbrown@cornell.edu>
>>> Cc: Emacs <emacs-devel@gnu.org>
>>>
>>> The build with dbus support still doesn't work.  An "Emacs abort"
>>> dialogue box comes up during the build [which I've never seen before
>>> when doing a Cygwin build] asking if I want to attach gdb.
>>
>> That dialog is one sign that the native Windows GUI and window manager
>> are used for display and input.  It's what happens when Emacs aborts
>> itself or catches some other fatal signal.
>>
>> Attaching a debugger, as instructed in the dialog, will allow you to
>> produce a backtrace that might show what went wrong.
> 
> I'm hoping that Daniel will be able to reproduce the problem and fix it.  If
> not, I'll try to debug it when I return from my trip.

I haven't seen this problem, but that's likely because I'm not running a full
desktop environment in Cygwin. I'll try setting up a dbus server and see whether
I can reproduce the issue. I wonder whether the dbus code has ever worked on a
non-X11 system.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

On 10/15/2012 12:35 PM, Daniel Colascione wrote:
> On 10/15/2012 12:33 PM, Ken Brown wrote:
>> On 10/15/2012 1:16 PM, Eli Zaretskii wrote:
>>>> Date: Mon, 15 Oct 2012 10:14:26 -0400
>>>> From: Ken Brown <kbrown@cornell.edu>
>>>> Cc: Emacs <emacs-devel@gnu.org>
>>>>
>>>> The build with dbus support still doesn't work.  An "Emacs abort"
>>>> dialogue box comes up during the build [which I've never seen before
>>>> when doing a Cygwin build] asking if I want to attach gdb.
>>>
>>> That dialog is one sign that the native Windows GUI and window manager
>>> are used for display and input.  It's what happens when Emacs aborts
>>> itself or catches some other fatal signal.
>>>
>>> Attaching a debugger, as instructed in the dialog, will allow you to
>>> produce a backtrace that might show what went wrong.
>>
>> I'm hoping that Daniel will be able to reproduce the problem and fix it.  If
>> not, I'll try to debug it when I return from my trip.
> 
> I haven't seen this problem, but that's likely because I'm not running a full
> desktop environment in Cygwin. I'll try setting up a dbus server and see whether
> I can reproduce the issue. I wonder whether the dbus code has ever worked on a
> non-X11 system.

Emacs builds and starts fine for me even when dbus-daemon is running, with or
without X also running. Running dbus-monitor doesn't report anything happening.
A stack trace from your environment would be helpful.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/15/2012 5:31 PM, Daniel Colascione wrote:
> On 10/15/2012 12:35 PM, Daniel Colascione wrote:
>> On 10/15/2012 12:33 PM, Ken Brown wrote:
>>> On 10/15/2012 1:16 PM, Eli Zaretskii wrote:
>>>>> Date: Mon, 15 Oct 2012 10:14:26 -0400
>>>>> From: Ken Brown <kbrown@cornell.edu>
>>>>> Cc: Emacs <emacs-devel@gnu.org>
>>>>>
>>>>> The build with dbus support still doesn't work.  An "Emacs abort"
>>>>> dialogue box comes up during the build [which I've never seen before
>>>>> when doing a Cygwin build] asking if I want to attach gdb.
>>>>
>>>> That dialog is one sign that the native Windows GUI and window manager
>>>> are used for display and input.  It's what happens when Emacs aborts
>>>> itself or catches some other fatal signal.
>>>>
>>>> Attaching a debugger, as instructed in the dialog, will allow you to
>>>> produce a backtrace that might show what went wrong.
>>>
>>> I'm hoping that Daniel will be able to reproduce the problem and fix it.  If
>>> not, I'll try to debug it when I return from my trip.
>>
>> I haven't seen this problem, but that's likely because I'm not running a full
>> desktop environment in Cygwin. I'll try setting up a dbus server and see whether
>> I can reproduce the issue. I wonder whether the dbus code has ever worked on a
>> non-X11 system.
>
> Emacs builds and starts fine for me even when dbus-daemon is running, with or
> without X also running. Running dbus-monitor doesn't report anything happening.
> A stack trace from your environment would be helpful.

OK.  It will probably be a week or so before I can do this, but there's 
a slight chance I'll get to it sooner.  Did you definitely build emacs 
with dbus support?  You need to have libdbus1-devel installed in order 
for this to happen.

Ken

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On 10/15/2012 2:34 PM, Ken Brown wrote:
> On 10/15/2012 5:31 PM, Daniel Colascione wrote:
>> Emacs builds and starts fine for me even when dbus-daemon is running, with or
>> without X also running. Running dbus-monitor doesn't report anything happening.
>> A stack trace from your environment would be helpful.
> 
> OK.  It will probably be a week or so before I can do this, but there's a slight
> chance I'll get to it sooner.  Did you definitely build emacs with dbus
> support?  You need to have libdbus1-devel installed in order for this to happen.

$ ldd emacs.exe
        ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x7de70000)
        kernel32.dll => /Windows/syswow64/kernel32.dll (0x7dd60000)
        KERNELBASE.dll => /Windows/syswow64/KERNELBASE.dll (0x7d850000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
        cygdbus-1-3.dll => /usr/bin/cygdbus-1-3.dll (0xc4140000)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        cyggif-4.dll => /usr/bin/cyggif-4.dll (0xc3900000)
        ...

Could you describe your test environment?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 4819 bytes --]

On 10/15/2012 5:36 PM, Daniel Colascione wrote:
> On 10/15/2012 2:34 PM, Ken Brown wrote:
>> On 10/15/2012 5:31 PM, Daniel Colascione wrote:
>>> Emacs builds and starts fine for me even when dbus-daemon is running, with or
>>> without X also running. Running dbus-monitor doesn't report anything happening.
>>> A stack trace from your environment would be helpful.
>>
>> OK.  It will probably be a week or so before I can do this, but there's a slight
>> chance I'll get to it sooner.  Did you definitely build emacs with dbus
>> support?  You need to have libdbus1-devel installed in order for this to happen.
>
> $ ldd emacs.exe
>          ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x7de70000)
>          kernel32.dll => /Windows/syswow64/kernel32.dll (0x7dd60000)
>          KERNELBASE.dll => /Windows/syswow64/KERNELBASE.dll (0x7d850000)
>          cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
>          cygdbus-1-3.dll => /usr/bin/cygdbus-1-3.dll (0xc4140000)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>          cyggif-4.dll => /usr/bin/cyggif-4.dll (0xc3900000)
>          ...
>
> Could you describe your test environment?

I'm running 64-bit Windows 7 with the 2012-09-17 Cygwin snapshot.  [I 
got similar results on a different machine with the 2012-10-12 
snapshot.]  The development packages I've installed are shown in the 
attached devel.txt file.  I'm building emacs with the command

./configure --with-w32 CFLAGS='-g -O0' && make

The Emacs abort dialogue box pops up when the build gets to this point:

gcc -std=gnu99  -Demacs  -I. -I/home/kbrown/src/emacs/test-w32/src 
-I../lib -I/home/kbrown/src/emacs/test-w32/src/../lib 
-I/usr/include/libxml2   -I/usr/include/dbus-1.0 
-I/usr/lib/dbus-1.0/include          -MMD -MF deps/.d -MP 
-I/usr/include/p11-kit-1      -g -O0   -L/usr/lib/noX \
   -o temacs pre-crt0.o dispnew.o frame.o scroll.o xdisp.o menu.o 
window.o  charset.o coding.o category.o ccl.o character.o chartab.o 
bidi.o  cm.o term.o terminal.o xfaces.o   dbusbind.o  emacs.o keyboard.o 
macros.o keymap.o sysdep.o  buffer.o filelock.o insdel.o marker.o 
minibuf.o fileio.o dired.o  cmds.o casetab.o casefiddle.o indent.o 
search.o regex.o undo.o  alloc.o data.o doc.o editfns.o callint.o 
eval.o floatfns.o fns.o font.o print.o lread.o  syntax.o unexcw.o 
bytecode.o  process.o gnutls.o callproc.o  region-cache.o sound.o 
atimer.o  doprnt.o intervals.o textprop.o composite.o xml.o  profiler.o 
     sheap.o cygw32.o   w32fns.o w32menu.o w32reg.o w32font.o w32term.o 
w32xfns.o w32select.o w32uniscribe.o fontset.o fringe.o image.o 
terminfo.o  gmalloc.o   lastfile.o vm-limit.o   ../lib/libgnu.a 
-lkernel32 -luser32 -lgdi32 -lole32 -lcomdlg32 -lusp10 -lcomctl32 
-lwinspool   -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm          -ldbus-1 
-lpthread -lrt      -lxml2 -lz -liconv -lm       -lncurses 
-L/usr/bin -lgnutls -lnettle -lhogweed -lgmp -ltasn1 -lp11-kit -lz 
-lpthread
test "no" = "yes" || \
   test "X" = X ||  -r temacs.exe
cd ../lisp; make -w update-subdirs
make[2]: Entering directory `/home/kbrown/src/emacs/test-w32/lisp'
cd /home/kbrown/src/emacs/test-w32/lisp; subdirs=`find . -type d 
-print`;  for file in $subdirs; do  case $file in */.* | */.*/* | */=* | 
*/cedet* ) ;;  *) wins="$wins $file" ;;  esac;  done; \
for file in $wins; do \
    /home/kbrown/src/emacs/test-w32/build-aux/update-subdirs $file; \
done;
make[2]: Leaving directory `/home/kbrown/src/emacs/test-w32/lisp'
if test "no" = "yes"; then \
   rm -f bootstrap-emacs.exe; \
   ln temacs.exe bootstrap-emacs.exe; \
else \
   `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
   test "X" = X ||  -zex emacs.exe; \
   mv -f emacs.exe bootstrap-emacs.exe; \
fi

At this point I attached gdb.  The session didn't provide any 
information that I can see, but I'm attaching a log (gdb.txt).

My build was based on the trunk as of bzr revision 110552.

FWIW, here's a stack trace from an earlier build attempt in which I 
didn't attach gdb and just let emacs abort:

0028A714  76A61194  (000001A8, 0000EA60, 00000000, 0028A848)
0028A728  76A61148  (000001A8, 0000EA60, 000000A4, 0028A824)
0028A848  610DC649  (03FA135C, 00000000, 03D4E5E8, 03FA13C8)
0028A938  610D9893  (00000000, 0000000A, 03D490B8, 03D490B8)
0028A998  610D9D6E  (00000008, 007B53C0, 6B00076C, 00000006)
0028AA48  610D9EC0  (00001FF8, 00000006, 03D219D8, 0028AA7C)
0028AA68  610D9EEC  (00000006, 00000006, FFFFFFFF, 0028AA98)
0028AA98  610DA1B3  (00000000, 00752438, 00752423, 00012034)
0028AAB8  005603C7  (0028AC24, 0028AAF0, 0028AB28, 00498BB4)
0028AAC8  004F070B  (0079E4EC, 007412BE, 0079E4EC, 0079B3B0)
0028AB28  00498BB4  (00800C92, 0080022A, 007B7432, 0028AC34)
0028AC58  0049A75A  (00000005, 0028AC80, 007A2F00, 611A1E96)
0028ACF8  6100763A  (00000000, 0028CD78, 61006C50, 00000000)



[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 7664 bytes --]

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 3672
[New Thread 3672.0x16cc]
[New Thread 3672.0x1c0]
[New Thread 3672.0x1e00]
Reading symbols from /home/kbrown/src/emacs/test-w32/src/temacs.exe...done.
warning: File "/home/kbrown/src/emacs/test-w32/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
(gdb) thread apply all bt full

Thread 3 (Thread 3672.0x1e00):
#0  0x7749000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7751f896 in ntdll!RtlQueryTimeZoneInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x7fe8a848 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 3672.0x1c0):
#0  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x765bdd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x000000a4 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 3672.0x16cc):
#0  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#1  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#2  0x75abcd46 in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 3672.0x1e00):
#0  0x7749000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7751f896 in ntdll!RtlQueryTimeZoneInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x7fe8a848 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 3672.0x1c0):
#0  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x765bdd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x000000a4 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 3672.0x16cc):
#0  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#1  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#2  0x75abcd46 in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 3672.0x1e00):
#0  0x7749000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7751f896 in ntdll!RtlQueryTimeZoneInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x7fe8a848 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 3672.0x1c0):
#0  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x765bdd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x000000a4 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 3672.0x16cc):
#0  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#1  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#2  0x75abcd46 in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 3672.0x1e00):
#0  0x7749000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7751f896 in ntdll!RtlQueryTimeZoneInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x7fe8a848 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 3672.0x1c0):
#0  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x765bdd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x000000a4 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 3672.0x16cc):
#0  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#1  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#2  0x75abcd46 in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 3672.0x1e00):
#0  0x7749000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7751f896 in ntdll!RtlQueryTimeZoneInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x7fe8a848 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 3672.0x1c0):
#0  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x765bdd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x000000a4 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 3672.0x16cc):
#0  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#1  0x75abf5be in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#2  0x75abcd46 in USER32!SetMessageExtraInfo ()
   from /c/windows/syswow64/USER32.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 3672.0x16cc]
0x765c321a in KERNELBASE!DeleteAce () from /c/windows/syswow64/KERNELBASE.dll
(gdb) c
Continuing.
[Inferior 1 (process 3672) exited with code 01000]

[-- Attachment #3: devel.txt --]
[-- Type: text/plain, Size: 6641 bytes --]

gettext-devel                                0.18.1.1-2
gnutls-devel                                 3.1.1-1
gsl-devel                                    1.15-1
libarchive-devel                             2.8.3-1
libatk1.0-devel                              2.4.0-1
libattr-devel                                2.4.46-1
libaudio-devel                               1.9.3-1
libavahi-client-devel                        0.6.31-1
libavahi-common-devel                        0.6.31-1
libavahi-glib-devel                          0.6.31-1
libbz2-devel                                 1.0.6-2
libcairo-devel                               1.12.2-1
libcroco0.6-devel                            0.6.5-1
libdatrie-devel                              0.2.4-1
libdb4.5-devel                               4.5.20.2-3
libdbus1-devel                               1.4.20-1
libdialog-devel                              1.1-20120706-1
libexpat1-devel                              2.1.0-1
libfam-devel                                 0.1.10-12
libfftw3-devel                               3.3.2-1
libfontconfig-devel                          2.10.1-1
libfpx-devel                                 1.3.1-1
libfreetype-devel                            2.4.10-1
libgcrypt-devel                              1.4.6-1
libgd-devel                                  2.0.36RC1-13
libgdbm-devel                                1.8.3-20
libgdk_pixbuf2.0-devel                       2.26.3-1
libgif-devel                                 4.1.6-10
libGL-devel                                  8.0.4-1
libglib2.0-devel                             2.32.4-1
libglitz-devel                               0.5.6-10
libGLU-devel                                 8.0.4-1
libglut-devel                                2.6.0-1
libgmp-devel                                 4.3.2-1
libgnome-keyring-devel                       3.4.1-1
libgpg-error-devel                           1.10-1
libgs-devel                                  9.06-1
libgsf1-devel                                1.14.24-1
libgtk2.0-devel                              2.24.12-1
libgtk3-devel                                3.4.4-1
libhunspell-devel                            1.3.2-1
libICE-devel                                 1.0.8-1
libicu-devel                                 4.8.1-1
libidn-devel                                 1.25-1
libjasper-devel                              1.900.1-12
libjbig-devel                                2.0-11
libjpeg-devel                                8b-1
libkpathsea-devel                            20120628-2
liblapack-devel                              3.4.2-1
liblcms-devel                                1.19-2
liblcms2-devel                               2.4-1
liblzma-devel                                5.0.2_20110517-1
liblzo2-devel                                2.06-1
libMagick-devel                              6.7.6.3-2
libncurses-devel                             5.7-18
libncursesw-devel                            5.7-18
libnettle-devel                              2.5-1
libopenjpeg-devel                            1.5.0-1
libp11-kit-devel                             0.12-1
libpango1.0-devel                            1.30.1-1
libpaper-devel                               1.1.24-1
libpcre-devel                                8.31-1
libpixman1-devel                             0.26.2-1
libpng-devel                                 1.5.12-1
libpng12-devel                               1.2.50-2
libpng14-devel                               1.4.12-3
libpoppler-devel                             0.20.5-1
libpoppler-qt4-devel                         0.20.5-1
libptexenc-devel                             20120628-2
libQtCore4-devel                             4.7.4-4
libQtDBus4-devel                             4.7.4-4
libQtDesigner4-devel                         4.7.4-4
libQtGui4-devel                              4.7.4-4
libQtScript4-devel                           4.7.4-4
libQtScriptTools4-devel                      4.7.4-4
libQtXml4-devel                              4.7.4-4
librsvg2-devel                               2.36.3-1
libSM-devel                                  1.2.1-1
libsoup-gnome2.4-devel                       2.38.1-1
libsoup2.4-devel                             2.38.1-1
libsqlite3-devel                             3.7.13-1
libstdc++6-devel                             4.5.3-3
libtasn1-devel                               2.14-1
libtdb-devel                                 1.2.9-1
libthai-devel                                0.1.15-1
libtiff-devel                                3.9.6-1
libuuid-devel                                2.21-1
libvala0.14-devel                            0.14.2-1
libwmf-devel                                 0.2.8.4-11
libX11-devel                                 1.5.0-1
libX11-xcb-devel                             1.5.0-1
libXau-devel                                 1.0.7-1
libXaw-devel                                 1.0.11-1
libxcb-devel                                 1.8.1-2
libxcb-glx-devel                             1.8.1-2
libxcb-render-devel                          1.8.1-2
libxcb-render-util-devel                     0.3.8-1
libxcb-shm-devel                             1.8.1-2
libXcomposite-devel                          0.4.3-1
libXcursor-devel                             1.1.13-1
libXdamage-devel                             1.1.3-1
libXdmcp-devel                               1.1.1-1
libXext-devel                                1.3.1-1
libXfixes-devel                              5.0-1
libXft-devel                                 2.3.1-1
libXi-devel                                  1.6.1-1
libXinerama-devel                            1.1.2-1
libxml2-devel                                2.8.0-1
libXmu-devel                                 1.1.1-1
libXpm-devel                                 3.5.10-1
libXpm-noX-devel                             3.5.7-12
libXrandr-devel                              1.3.2-1
libXrender-devel                             0.9.7-1
libxslt-devel                                1.1.27-1
libXt-devel                                  1.1.3-1
libzzip-devel                                0.13.60-1
mingw-libbz2-devel                           1.0.6-1
mingw-libgcrypt-devel                        1.4.6-1
mingw-libgpg-error-devel                     1.10-1
mingw-liblzma-devel                          5.0.2_20110517-1
mingw-zlib-devel                             1.2.7-1
openssl-devel                                1.0.1c-2
t1lib-devel                                  5.1.2-11
zlib-devel                                   1.2.7-1

Re: Is the Cygw32 port ready for testing?

[Eli Zaretskii]

> Date: Tue, 16 Oct 2012 09:23:28 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> ./configure --with-w32 CFLAGS='-g -O0' && make
> 
> The Emacs abort dialogue box pops up when the build gets to this point:
> 
> gcc -std=gnu99  -Demacs  -I. -I/home/kbrown/src/emacs/test-w32/src 
> -I../lib -I/home/kbrown/src/emacs/test-w32/src/../lib 
> -I/usr/include/libxml2   -I/usr/include/dbus-1.0 
> -I/usr/lib/dbus-1.0/include          -MMD -MF deps/.d -MP 
> -I/usr/include/p11-kit-1      -g -O0   -L/usr/lib/noX \
>    -o temacs pre-crt0.o dispnew.o frame.o scroll.o xdisp.o menu.o 
> window.o  charset.o coding.o category.o ccl.o character.o chartab.o 
> bidi.o  cm.o term.o terminal.o xfaces.o   dbusbind.o  emacs.o keyboard.o 
> macros.o keymap.o sysdep.o  buffer.o filelock.o insdel.o marker.o 
> minibuf.o fileio.o dired.o  cmds.o casetab.o casefiddle.o indent.o 
> search.o regex.o undo.o  alloc.o data.o doc.o editfns.o callint.o 
> eval.o floatfns.o fns.o font.o print.o lread.o  syntax.o unexcw.o 
> bytecode.o  process.o gnutls.o callproc.o  region-cache.o sound.o 
> atimer.o  doprnt.o intervals.o textprop.o composite.o xml.o  profiler.o 
>      sheap.o cygw32.o   w32fns.o w32menu.o w32reg.o w32font.o w32term.o 
> w32xfns.o w32select.o w32uniscribe.o fontset.o fringe.o image.o 
> terminfo.o  gmalloc.o   lastfile.o vm-limit.o   ../lib/libgnu.a 
> -lkernel32 -luser32 -lgdi32 -lole32 -lcomdlg32 -lusp10 -lcomctl32 
> -lwinspool   -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm          -ldbus-1 
> -lpthread -lrt      -lxml2 -lz -liconv -lm       -lncurses 
> -L/usr/bin -lgnutls -lnettle -lhogweed -lgmp -ltasn1 -lp11-kit -lz 
> -lpthread
> test "no" = "yes" || \
>    test "X" = X ||  -r temacs.exe
> cd ../lisp; make -w update-subdirs
> make[2]: Entering directory `/home/kbrown/src/emacs/test-w32/lisp'
> cd /home/kbrown/src/emacs/test-w32/lisp; subdirs=`find . -type d 
> -print`;  for file in $subdirs; do  case $file in */.* | */.*/* | */=* | 
> */cedet* ) ;;  *) wins="$wins $file" ;;  esac;  done; \
> for file in $wins; do \
>     /home/kbrown/src/emacs/test-w32/build-aux/update-subdirs $file; \
> done;
> make[2]: Leaving directory `/home/kbrown/src/emacs/test-w32/lisp'
> if test "no" = "yes"; then \
>    rm -f bootstrap-emacs.exe; \
>    ln temacs.exe bootstrap-emacs.exe; \
> else \
>    `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
>    test "X" = X ||  -zex emacs.exe; \
>    mv -f emacs.exe bootstrap-emacs.exe; \
> fi

Does it also crash if you invoke the following command from the Bash
prompt in the src directory?

  ./temacs --batch --load loadup bootstrap

If this also crashes, then please run the same command from GDB, and
see what happens.

> At this point I attached gdb.  The session didn't provide any 
> information that I can see, but I'm attaching a log (gdb.txt).
> [...]
> GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-cygwin".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Attaching to process 3672
> [New Thread 3672.0x16cc]
> [New Thread 3672.0x1c0]
> [New Thread 3672.0x1e00]
> Reading symbols from /home/kbrown/src/emacs/test-w32/src/temacs.exe...done.
> warning: File "/home/kbrown/src/emacs/test-w32/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

If you want to debug Emacs conveniently, you need to take care of that
"warning", because you do need GDB to load .gdbinit.

> (gdb) thread apply all bt full

You need to say "continue" first.  (Doesn't the Abort dialog say so?)

> Thread 1 (Thread 3672.0x16cc):
> #0  0x75abf5be in USER32!SetMessageExtraInfo ()
>    from /c/windows/syswow64/USER32.dll
> No symbol table info available.
> #1  0x75abf5be in USER32!SetMessageExtraInfo ()
>    from /c/windows/syswow64/USER32.dll
> No symbol table info available.
> #2  0x75abcd46 in USER32!SetMessageExtraInfo ()
>    from /c/windows/syswow64/USER32.dll
> No symbol table info available.
> #3  0x00000000 in ?? ()
> No symbol table info available.

Any idea why it says "No symbol table info available"?  There's no -s
switch on the link command line.

Also, why did you use CFLAGS='-g -O0', rather than CFLAGS='-g3 -O0'?
The latter would produce a much richer debug info.  (But I don't think
it has anything to do with the crash or the lack of debug info.)

Re: Is the Cygw32 port ready for testing?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > Reading symbols from /home/kbrown/src/emacs/test-w32/src/temacs.exe...done.
 > > warning: File "/home/kbrown/src/emacs/test-w32/src/.gdbinit"
 > > auto-loading has been declined by your `auto-load safe-path' set
 > > to "$debugdir:$datadir/auto-load".
 > 
 > If you want to debug Emacs conveniently, you need to take care of that
 > "warning", because you do need GDB to load .gdbinit.

"source .gdbinit" will do the trick.

Re: Is the Cygw32 port ready for testing?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: Ken Brown <kbrown@cornell.edu>,
>     dancol@dancol.org,
>     emacs-devel@gnu.org
> Date: Wed, 17 Oct 2012 13:13:06 +0900
> 
> Eli Zaretskii writes:
>  > > Reading symbols from /home/kbrown/src/emacs/test-w32/src/temacs.exe...done.
>  > > warning: File "/home/kbrown/src/emacs/test-w32/src/.gdbinit"
>  > > auto-loading has been declined by your `auto-load safe-path' set
>  > > to "$debugdir:$datadir/auto-load".
>  > 
>  > If you want to debug Emacs conveniently, you need to take care of that
>  > "warning", because you do need GDB to load .gdbinit.
> 
> "source .gdbinit" will do the trick.

But is very annoying, especially when you say "gdb --args ./emacs ..."
and expect the initial setup to work right from the start.

There are better solutions.

Re: Is the Cygw32 port ready for testing?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>

 > > "source .gdbinit" will do the trick.
 > 
 > But is very annoying, especially when you say "gdb --args ./emacs ..."
 > and expect the initial setup to work right from the start.
 > 
 > There are better solutions.

Sure, but C-d, fix your gdb setup, and restart gdb and emacs isn't one
of them for *this* time.

Re: Is the Cygw32 port ready for testing?

[Nix]

On 17 Oct 2012, Stephen J. Turnbull said:

> Eli Zaretskii writes:
>  > > Reading symbols from /home/kbrown/src/emacs/test-w32/src/temacs.exe...done.
>  > > warning: File "/home/kbrown/src/emacs/test-w32/src/.gdbinit"
>  > > auto-loading has been declined by your `auto-load safe-path' set
>  > > to "$debugdir:$datadir/auto-load".
>  > 
>  > If you want to debug Emacs conveniently, you need to take care of that
>  > "warning", because you do need GDB to load .gdbinit.
>
> "source .gdbinit" will do the trick.

Alternatively, putting

set auto-load safe-path /

in your ~/.gdbinit will turn off this dubious 'security' feature
entirely. (Has any system *ever* been taken over by a hostile .gdbinit?
I suppose if you have hostile local users who are looking for really
obscure ways to screw you up, and routinely run gdb in /tmp or in their
home directories the feature has some value. But how often does *that*
happen? And isn't it likely that such a user would pick an attack vector
more likely to be hit? Bah.)

-- 
NULL && (void)

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/16/2012 2:24 PM, Eli Zaretskii wrote:
>> Date: Tue, 16 Oct 2012 09:23:28 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> ./configure --with-w32 CFLAGS='-g -O0' && make
>>
>> The Emacs abort dialogue box pops up when the build gets to this point:
>>
>> gcc -std=gnu99  -Demacs  -I. -I/home/kbrown/src/emacs/test-w32/src
>> -I../lib -I/home/kbrown/src/emacs/test-w32/src/../lib
>> -I/usr/include/libxml2   -I/usr/include/dbus-1.0
>> -I/usr/lib/dbus-1.0/include          -MMD -MF deps/.d -MP
>> -I/usr/include/p11-kit-1      -g -O0   -L/usr/lib/noX \
>>     -o temacs pre-crt0.o dispnew.o frame.o scroll.o xdisp.o menu.o
>> window.o  charset.o coding.o category.o ccl.o character.o chartab.o
>> bidi.o  cm.o term.o terminal.o xfaces.o   dbusbind.o  emacs.o keyboard.o
>> macros.o keymap.o sysdep.o  buffer.o filelock.o insdel.o marker.o
>> minibuf.o fileio.o dired.o  cmds.o casetab.o casefiddle.o indent.o
>> search.o regex.o undo.o  alloc.o data.o doc.o editfns.o callint.o
>> eval.o floatfns.o fns.o font.o print.o lread.o  syntax.o unexcw.o
>> bytecode.o  process.o gnutls.o callproc.o  region-cache.o sound.o
>> atimer.o  doprnt.o intervals.o textprop.o composite.o xml.o  profiler.o
>>       sheap.o cygw32.o   w32fns.o w32menu.o w32reg.o w32font.o w32term.o
>> w32xfns.o w32select.o w32uniscribe.o fontset.o fringe.o image.o
>> terminfo.o  gmalloc.o   lastfile.o vm-limit.o   ../lib/libgnu.a
>> -lkernel32 -luser32 -lgdi32 -lole32 -lcomdlg32 -lusp10 -lcomctl32
>> -lwinspool   -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm          -ldbus-1
>> -lpthread -lrt      -lxml2 -lz -liconv -lm       -lncurses
>> -L/usr/bin -lgnutls -lnettle -lhogweed -lgmp -ltasn1 -lp11-kit -lz
>> -lpthread
>> test "no" = "yes" || \
>>     test "X" = X ||  -r temacs.exe
>> cd ../lisp; make -w update-subdirs
>> make[2]: Entering directory `/home/kbrown/src/emacs/test-w32/lisp'
>> cd /home/kbrown/src/emacs/test-w32/lisp; subdirs=`find . -type d
>> -print`;  for file in $subdirs; do  case $file in */.* | */.*/* | */=* |
>> */cedet* ) ;;  *) wins="$wins $file" ;;  esac;  done; \
>> for file in $wins; do \
>>      /home/kbrown/src/emacs/test-w32/build-aux/update-subdirs $file; \
>> done;
>> make[2]: Leaving directory `/home/kbrown/src/emacs/test-w32/lisp'
>> if test "no" = "yes"; then \
>>     rm -f bootstrap-emacs.exe; \
>>     ln temacs.exe bootstrap-emacs.exe; \
>> else \
>>     `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
>>     test "X" = X ||  -zex emacs.exe; \
>>     mv -f emacs.exe bootstrap-emacs.exe; \
>> fi
>
> Does it also crash if you invoke the following command from the Bash
> prompt in the src directory?
>
>    ./temacs --batch --load loadup bootstrap

Yes.

> If this also crashes, then please run the same command from GDB, and
> see what happens.

Here's the gdb session:

$ gdb ./temacs.exe
GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/kbrown/src/emacs/test-w32/src/temacs.exe...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from 
terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm
Breakpoint 1 at 0x4ce176: file emacs.c, line 317.
Temporary breakpoint 2 at 0x4ebbce: file sysdep.c, line 794.
(gdb) r --batch --load loadup bootstrap
Starting program: /home/kbrown/src/emacs/test-w32/src/temacs.exe --batch 
--load loadup bootstrap
[New Thread 3812.0x253c]
[New Thread 3812.0x80c]
Program received signal SIGTRAP, Trace/breakpoint trap.
0x765c321a in KERNELBASE!DeleteAce () from 
/c/windows/syswow64/KERNELBASE.dll
(gdb) thread apply all bt full

Thread 2 (Thread 3812.0x80c):
#0  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
    from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7749f8e5 in ntdll!RtlUpdateClonedSRWLock ()
    from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x765bdd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000098 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 3812.0x253c):
#0  0x765c321a in KERNELBASE!DeleteAce ()
    from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#1  0x005bf093 in emacs_abort () at w32fns.c:7706
         button = 6
#2  0x00536928 in staticpro (varaddress=0x807c8c) at alloc.c:5033
No locals.
#3  0x005786cc in defvar_lisp (o_fwd=0x7d35fc,
     namestring=0x7a966d "dbus-runtime-version", address=0x807c8c)
     at lread.c:4055
No locals.
#4  0x004cdfc8 in syms_of_dbusbind () at dbusbind.c:1777
         o_fwd = {
           type = Lisp_Fwd_Obj,
           objvar = 0x807c8c
         }
#5  0x004cf84b in main (argc=5, argv=0x28ac10) at emacs.c:1439
         dummy = 1
         stack_bottom_variable = 0 '\000'
         do_initial_setlocale = true
         dumping = true
         skip_args = 1
         rlim = {
           rlim_cur = 2097152,
           rlim_max = 2097152
         }
         no_loadup = false
         junk = 0x0
         dname_arg = 0x0
         dname_arg2 = 
"\001\000\000\000(\000\000\000\000\000X\253(\000O\255\025a 
\330#a\340\324\037a \336#ax\336#a\300x\023a(\000\001\000\000\000 
\330#a(\000\000\000\000\000\030\254(\000\355\202\022a\340r\030a \330#a("
         ch_to_dir = 0x695f656d <Address 0x695f656d out of bounds>
(gdb) c
Continuing.
[Inferior 1 (process 3812) exited with code 02]

Re: Is the Cygw32 port ready for testing?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

Thanks for debugging this problem.

On 10/18/2012 5:28 AM, Ken Brown wrote:
> Thread 1 (Thread 3812.0x253c):
> #1  0x005bf093 in emacs_abort () at w32fns.c:7706
>         button = 6
> #2  0x00536928 in staticpro (varaddress=0x807c8c) at alloc.c:5033

I've updated trunk with the following patch. Please try it now.

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-10-10 15:31:21 +0000
+++ src/alloc.c	2012-10-18 16:54:49 +0000
@@ -376,7 +376,7 @@
 /* Addresses of staticpro'd variables.  Initialize it to a nonzero
    value; otherwise some compilers put it into BSS.  */

-#define NSTATICS 0x650
+#define NSTATICS 0x1000
 static Lisp_Object *staticvec[NSTATICS] = {&Vpurify_flag};

 /* Index of next unused slot in staticvec.  */
@@ -5030,7 +5030,7 @@
 {
   staticvec[staticidx++] = varaddress;
   if (staticidx >= NSTATICS)
-    emacs_abort ();
+    fatal ("NSTATICS too small. Try increasing and recompiling Emacs.");
 }




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Is the Cygw32 port ready for testing?

[Ken Brown]

On 10/18/2012 1:02 PM, Daniel Colascione wrote:
> Thanks for debugging this problem.
>
> On 10/18/2012 5:28 AM, Ken Brown wrote:
>> Thread 1 (Thread 3812.0x253c):
>> #1  0x005bf093 in emacs_abort () at w32fns.c:7706
>>          button = 6
>> #2  0x00536928 in staticpro (varaddress=0x807c8c) at alloc.c:5033
>
> I've updated trunk with the following patch. Please try it now.

It builds for me now.

Thanks.

Ken

Re: Is the Cygw32 port ready for testing?

[Eli Zaretskii]

> Date: Thu, 18 Oct 2012 08:28:14 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: dancol@dancol.org, emacs-devel@gnu.org
> 
> #1  0x005bf093 in emacs_abort () at w32fns.c:7706
>          button = 6
> #2  0x00536928 in staticpro (varaddress=0x807c8c) at alloc.c:5033
> No locals.

This just means NSTATIC should be bumped up again (which Daniel
already did, I see).

I think going from 0x650 to 0x1000 is too much.  But I'll let Stefan
decide.

Re: Is the Cygw32 port ready for testing?

[Stefan Monnier]

> This just means NSTATIC should be bumped up again (which Daniel
> already did, I see).

> I think going from 0x650 to 0x1000 is too much.  But I'll let Stefan
> decide.

I'm not too worried about those 20KB, but yes, 0x800 sounds like
a better choice.


        Stefan

Re: Is the Cygw32 port ready for testing?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Ken Brown <kbrown@cornell.edu>,  dancol@dancol.org,  emacs-devel@gnu.org
> Date: Thu, 18 Oct 2012 18:04:38 -0400
> 
> > This just means NSTATIC should be bumped up again (which Daniel
> > already did, I see).
> 
> > I think going from 0x650 to 0x1000 is too much.  But I'll let Stefan
> > decide.
> 
> I'm not too worried about those 20KB, but yes, 0x800 sounds like
> a better choice.

Done.