i bet there's something subtle going wrong with vc 6 on windows xp, since it's
the build os, not the run os, that matters. this makes some sense since windows
xp didn't exist when vc 6 was created.
it may be that all we can do is put something in PROBLEMS. i dunno. if you can
track down further what's being miscompiled, we may be able to work around it.
[often, it's an expression that's miscompiled, and it's enough to simplify it
using temporary variables.]
but you have to find where the problem is -- that's the rub. if you're patient,
you could try copying over some of the .obj files and relinking -- with a
binary-search-type approach, you can maybe find a single file that's
problematic. to get farther, though, you have to look at the assembly, which is
difficult. [maybe you could get the compiler to output assembly language and do
a diff ...]
----- Original Message -----
From: "Paul Moore" <gustav(a)morpheus.demon.co.uk>
To: "Ben Wing" <ben(a)666.com>
Sent: Tuesday, March 11, 2003 2:41 PM
Subject: Re: Error if locale is omitted in set-progress-feedback-instantiator
"Paul Moore" <gustav(a)morpheus.demon.co.uk> writes:
> PS Just tried this on my Windows 2000 box, and it works perfectly
Actually, with the "broken" version on my XP Home box, xemacs -q -f
message-mail wasn't enough. It needed something extra from my Gnus
setup to trigger the problem. I don't know what, though (Yes I do! See
> I'll copy the exact installed tree to my XP Home box this evening, and
> see if it fails there. (It may be that -q -f message-mail isn't enough
> to reproduce the problem. I'll try to get a minimal case that triggers
> the bug if that's the case).
Ack. I copied the directory tree built on Win2000 across unchanged,
and ran Gnus. No bug. So the same sources, with the same version of
MSVC6, built (as far as I can manage) the same, run on the same box,
with the same configuration, work fine when the build was done on
Windows 2000, but fail when the build was done on XP Home.
I did a complete diff of the 2 installed trees. The only files which
* The executables
* The elc files under XEmacs-21.5-b11/lisp
* The elc files under xemacs-packages/lisp/gnus
Why would the elc files differ? Are they not architecture independent?
Could this point to a problem in the byte-compiler somehow? [Nope, I
looked at a bytecode file, the username and machine the bytecode was
compiled on is in there. So that's a red herring...]
I'm baffled. I'll do a few more experiments...
OK, after a bit more checking, the only file that matters is the
executable. Running the EXE built on XP fails with the bug, running
the one built on 2K works, when the executable is in the exact same
installation tree. (I copied both exes into both trees, the 2K exe
worked in both, the XP exe failed in both).
Right. I did a binary search on the initialisation files. The line
that causes the problem is in my custom.el custom-set-variables
'(font-lock-mode nil nil (font-lock))
I've no idea why this breaks one build but not the other.
Just as a check, I looked at (current-locale) on both machines. Both
show "English_United States.1252", so that doesn't look relevant...
I'm out of ideas now. Any suggestions?
This signature intentionally left blank