Re: Windows mingw64 and cygwin builds broken

[Eli Zaretskii <eliz@gnu.org>]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Fri, 13 Nov 2015 09:58:33 +0000
> 
> >> ./dbusbind.c:1704:  DEFSYM (QCdbus_timeout, ":timeout");
> >> ./w32fns.c:9302:  DEFSYM (QCtimeout, ":timeout");
> >
> > Does this mean that your MinGW64 build uses D-Bus?  If so, it
> > shouldn't use the native w32 tray notifications.  I've pushed a change
> > to that effect, please test.  If you can afford testing MinGW64 also
> > without D-Bus, I'd appreciate that.
> 
> I dont use D-Bus, but it may be detected by configure in the mingw64
> build.

Is HAVE_DBUS defined in src/config.h?  Is src/dbusbind.c compiled, and
do you see src/dbusbind.o in your MinGW64 build?

> Your patch fails to build on mingw64:
> 
> ./temacs --batch --load loadup bootstrap
> 
> ../../src/lread.c:3787: Emacs fatal error: assertion failed: INTEGERP (bucket)
> Fatal error 6: Aborted

With or without commit 508e77b?  I had one more thinko fixed there.

If this is with 508e77b, then I don't understand what's going on:
there should be only one definition of ':timeout', the one in
dbusbind.c.

> Backtrace:
> 0x100694f9a
> 0x100695011
> 0x1005f8cad
> 0x10054149b
> 0x100599c8d
> 0x10053c757
> 0x10053a216
> 0x1005d092f
> 0x1006315bc
> 0x100631f58
> 0x10053b7ed
> 0x180048365
> 0x180046074
> 0x18004610c
> 0x1006ed999
> 0x100401008
> 0x76cd5a45
> 0x76e0b829

Can you convert this to human-readable backtrace, or run the same
command under GDB and show a backtrace?

> >> Renaming QCdbus_timeout to QCtimeout allows the cygwin-w32 and mingw64
> >> builds to bootstrap successfully (I don't know if that is the right
> >> fix though). Should the other keyword argument symbols in dbusbind.c
> >> also be renamed QCdbus_* -> QC* ?
> >
> > I don't understand why dbusbind.c uses such a non-standard naming
> > convention.  Michael?
> 
> If the patch renamed the C symbols to use the normal convention, then it
> appears that there is no harm in havng two modules declare identical
> symbols in syms_of_*(). 

Yes, but I still want to understand the reasons for this naming
convention, and I think we need to avoid calling DEFSYM twice even for
the same name.