emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Windows mingw64 and cygwin builds broken


From: Andy Moreton
Subject: Re: Windows mingw64 and cygwin builds broken
Date: Fri, 13 Nov 2015 09:58:33 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5.50 (windows-nt)

On Fri 13 Nov 2015, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Fri, 13 Nov 2015 02:11:36 +0000
>> 
>> > ./temacs --batch --load loadup bootstrap
>> >
>> > /cygdrive/c/emacs/git/emacs/master/src/lread.c:3787: Emacs fatal error: 
>> > assertion failed: INTEGERP (bucket)
>> > Fatal error 6: Aborted: paxctl -zex emacs.exe
>> > mv -f emacs.exe bootstrap-emacs.exe
>> > mv: cannot stat ‘emacs.exe’: No such file or directory
>> > Makefile:707: recipe for target 'bootstrap-emacs.exe' failed
>> 
>> This appears to be caused by a clash between symbols:
>> 
>> ./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. 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
Backtrace:
0x100694f9a
0x100695011
0x1005f8cad
0x10054149b
0x100599c8d
0x10053c757
0x10053a216
0x1005d092f
0x1006315bc
0x100631f58
0x10053b7ed
0x180048365
0x180046074
0x18004610c
0x1006ed999
0x100401008
0x76cd5a45
0x76e0b829
Makefile:707: recipe for target 'bootstrap-emacs.exe' failed

>> 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_*(). 

    AndyM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]