Re: Installing XEmacs under Cygwin

I spent some time this afternoon trying to get back into this. I pulled the latest upstream commit, merged it with my local 64-bit world and recompiled for MSQ successfully with gcc (although running the result gives an odd warning during init file loading which didn't use to be there: (1) (bad-variable/warning) Invalid 'default-buffer-file-coding-system', set to nil ) In order to track _that_ down, I attempted to build a clean 32bit MSW upstream system, which didn't work out of the box :-(. '--with-mule=yes' '--with-ncurses=yes' '--with-msw=yes' '--with-png' '--with-xpm' '--with-jpeg' '--with-database=no' '--with-tls=no' failed with a PANIC at the end, while trying and failing to load X11 libraries (which I don't have). I couldn't see an obvious way to fix this (--without-x11, which has worked in the past, was rejected as an unknown switch), finally had to do '--with-mule=yes' '--with-ncurses=yes' '--with-msw=yes' '--with-png' '--with-xpm' '--with-jpeg' '--with-database=no' '--with-tls=no' which worked, built, and ran OK as far as I can see, i.e. without the coding-system warning (although it is using the same init files as my 64-bit build). Back to 64-bit, did a distclean and a much simple config than my standard, namely (--without-x11 not working here either). No change -- still getting (1) (bad-variable/warning) Invalid 'default-buffer-file-coding-system', set to nil And I note that whereas my February 64-bit build not only doesn't have this problem, but if you edit a file it shows MSW-MB in the modeline for *scratch* and files it's editting (as does the new 32-bit build), whereas the new build shows Binary So something has changed in the file-coding space, and it's interacting badly (?) with the 64-bit patches or Cygwin environment. After some further hacking to preserve some information in the lookup process, the problem is that mswindows-multibyte-unix is not recognised as a coding system in the 64-bit build, but is in the 32-bit case. Futhermore, doing xemacs -q, then loading lisp/mule/mule-win32-init and loading user init file fixed the problem. Finally, figured out that preloaded-file-list included mule-win32-init in the 32-bit build, but not the 64. Finally! The actual bug is in dumped-lisp.el, where system-type is checked against '(windows-nt cygwin32), but in Vin's version of s/cygwin64.h he defined SYSTEM-TYPE to be cygwin64. I checked, and there are a number of other places where system-type is checked for cygwin32, mostly in conjunction with windows-nt. My _guess_ is that most if not all of these should be changed to include cygwin64. Thoughts? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta