[Top][All Lists]

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

bug#8562: Emacs 23.1 and later don't work in windows 98

From: oslsachem
Subject: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sun, 22 May 2011 23:32:22 +0200

> We actually need to be able to debug a binary produced with --no-opt,
> since debugging an optimized binary is hopeless.  What versions of GCC
> and GDB do you have?


> Also, since you are able to build your own Emacs binary, it would be
> best to use one of the versions that are currently being maintained:
> either the emacs-23 branch or the trunk of the Emacs bzr repository.

I have tried to build the trunk of the Emacs bzr repository under
Windows 98 but the building process gets stuck at a line which
presumably can't be handled by command.com or win95cmd.exe (more about
it below) because it makes use of standard handles redirection (2>&1)
and logical operators (||) and because win98's version of fc doesn't
seem to output a value for || to use (in the case of win95cmd.exe,
MinGW's version of cmp can be used for this).

After this, the bootstrapping process fails to compile some lisp files
showing fatal error dialogs and, after accepting them, skips those
files and continues with the building process. I didn't get to the end
of it because eventually there were too many lisp files that prompted
an error dialog window and required input from me to continue.

I've tried to copy a lisp directory with precompiled lisp files and
build from there without bootstrapping.




And this is a GDB session:


And I have tried running these same binaries under windows XP:


I have been able to build the trunk of the Emacs bzr repository under
Windows XP (using exacly the same version of MinGW), although the
bootstrapping process prompts me with a new command line shell
instance inside the original one and stops, and I have to type "exit"
to continue with the building process.

I provide the logs:




I have copied those binaries with their corresponding source files
from Windows XP to the windows 98 system, and the same graphical
glitch still appears, though this isn't reflected in the debugging
session which doesn't show any error. Superficially, the program is
functional: I can write to the *scratch* buffer (though it isn't
visible) and save it to a file. Not only the application window is
clipped to a small size but the tooltip rectangles as well. They
appear as small squares of a few pixels of side.


Is it necessary that the binaries are built on the same OS that they
are going to be debugged in?
Obviously, the official binary release of the Windows version of Emacs
is going to be "cross-compiled" but berhaps an error spotted on the
"natively built" binaries could give a hint about the cause of the
graphical glitch? Or could it become an added problem to solve?

> If this is hard or bumps into problems, it's not a catastrophe; we can
>continue debugging Emacs 23.3.
> In any case, being able to debug a --no-opt binary is imperative.
> Please try solving that problem, perhaps by up- or down-grading to
> other versions of GCC or GDB.

I have been able to build non-optimized binaries of Emacs 23.3 (that
is, with a symbol table that GDB can read) by using an alternative
command line shell from microsoft named Win95Cmd.exe ( from
Down-grading to other versions of GCC or GDB (I was using the latest
versions available from MinGW) didn't change the results.




Unlike when I used the officially released binaries, I couldn't even
get to the initial Emacs window by executing these binaries (either
from Emacs-23.3 or from bazaar's trunk). The process was interrupted
with a fatal error (though the -nw version (text console) worked
without problems).

I provide the log of a GDB session:


I have tried running that binary under windows XP with identical result:


I have tried building Emacs-23.3 under windows XP and debugging it
under windows 98 (by copying the whole directory). It hangs showing a
fatal error too, but at least the initial Emacs window appears (though
still at that small size)


Lastly, I have noticed that, when I run Emacs-22.3 (which I can both
build and execute under Windows 98 without errors or graphical
glitches) inside GDB, a "-geometry" option flag with a default initial
window size appears automatically appended to the binary name in the
debugger output. This doesn't happen in the other versions of Emacs
(23.3 or Trunk). I provide the log for this:



reply via email to

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