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 :-(.

  > ./configure  '--with-pdump=yes' '--with-modules=no'
'--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_x11=no ./configure  '--with-pdump=yes' '--with-modules=no'
'--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

  > with_x11=no ./configure  '--with-pdump' '--with-modules=no' '--with-mule'

(--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: [email protected]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]