On Wed, Mar 17, 2010 at 5:47 AM, Francis Wright <[email protected]>wrote:
> Maybe emacs can’t find its lisp directory. There should be a directory > called “lisp” under “emacs-23.1” and at the same level as “bin”, and it > should contain a lot of .el and .elc files and 20 subdirectories also > containing such files. > > > The lisp directory is there, and has a lot of el end elc files. I also made a copy of the lisp directory and deleted the elc files in the original, in case there was some problem with the compilation, but that gave the same results. Drew: using a shortcut to runemacs.exe works just like running runemacs directly. This morning (after a reboot and installing gdb) both of them create an emacs process in the task manager. Eli: emacs -Q also hangs. Running gdb on that process gives the following. $ gdb --pid=2316 GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin". Attaching to process 2316 [New thread 2316.0xde0] [New thread 2316.0x93c] Reading symbols from /home/udalrich/emacs/emacs-23.1/bin/emacs.exe...done. Reading symbols from /c/WINDOWS/system32/ntdll.dll...done. Loaded symbols for /c/WINDOWS/system32/ntdll.dll Reading symbols from /c/WINDOWS/system32/kernel32.dll...done. Loaded symbols for /c/WINDOWS/system32/kernel32.dll Reading symbols from /c/WINDOWS/system32/ADVAPI32.DLL...done. Loaded symbols for /c/WINDOWS/system32/ADVAPI32.DLL Reading symbols from /c/WINDOWS/system32/RPCRT4.dll...done. Loaded symbols for /c/WINDOWS/system32/RPCRT4.dll Reading symbols from /c/WINDOWS/system32/Secur32.dll...done. Loaded symbols for /c/WINDOWS/system32/Secur32.dll Reading symbols from /c/WINDOWS/WinSxS/X86_Microsoft.Windows.Common-Controls_659 5b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83/COMCTL32.DLL...done. Loaded symbols for /c/WINDOWS/WinSxS/X86_Microsoft.Windows.Common-Controls_6595b 64144ccf1df_6.0.2600.5512_x-ww_35d4ce83/COMCTL32.DLL Reading symbols from /c/WINDOWS/system32/msvcrt.dll...done. Loaded symbols for /c/WINDOWS/system32/msvcrt.dll Reading symbols from /c/WINDOWS/system32/GDI32.dll...done. Loaded symbols for /c/WINDOWS/system32/GDI32.dll Reading symbols from /c/WINDOWS/system32/USER32.dll...done. Loaded symbols for /c/WINDOWS/system32/USER32.dll Reading symbols from /c/WINDOWS/system32/SHLWAPI.dll...done. Loaded symbols for /c/WINDOWS/system32/SHLWAPI.dll Reading symbols from /c/WINDOWS/system32/COMDLG32.DLL...done. Loaded symbols for /c/WINDOWS/system32/COMDLG32.DLL Reading symbols from /c/WINDOWS/system32/SHELL32.dll...done. Loaded symbols for /c/WINDOWS/system32/SHELL32.dll Reading symbols from /c/WINDOWS/system32/MPR.DLL...done. Loaded symbols for /c/WINDOWS/system32/MPR.DLL Reading symbols from /c/WINDOWS/system32/OLE32.dll...done. Loaded symbols for /c/WINDOWS/system32/OLE32.dll Reading symbols from /c/WINDOWS/system32/USP10.DLL...done. Loaded symbols for /c/WINDOWS/system32/USP10.DLL Reading symbols from /c/WINDOWS/system32/WINMM.DLL...done. Loaded symbols for /c/WINDOWS/system32/WINMM.DLL Reading symbols from /c/WINDOWS/system32/WINSPOOL.DRV...done. Loaded symbols for /c/WINDOWS/system32/WINSPOOL.DRV Reading symbols from /c/WINDOWS/system32/IMM32.DLL...done. Loaded symbols for /c/WINDOWS/system32/IMM32.DLL Reading symbols from /c/WINDOWS/system32/uxtheme.dll...done. Loaded symbols for /c/WINDOWS/system32/uxtheme.dll Reading symbols from /c/WINDOWS/system32/MSCTF.dll...done. Loaded symbols for /c/WINDOWS/system32/MSCTF.dll Reading symbols from /c/WINDOWS/system32/apphelp.dll...done. Loaded symbols for /c/WINDOWS/system32/apphelp.dll Reading symbols from /c/WINDOWS/system32/msctfime.ime...done. Loaded symbols for /c/WINDOWS/system32/msctfime.ime [Switching to thread 2316.0x93c] (gdb) bt #0 0x7c90120f in ntdll!DbgUiConnectToDbg () from /c/WINDOWS/system32/ntdll.dll #1 0x7c951e40 in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll #2 0x00000005 in ?? () #3 0x00000004 in ?? () #4 0x00000001 in ?? () #5 0x0190ffd0 in ?? () #6 0x00000000 in ?? () (gdb) info frame Stack level 0, frame at 0x190ffd0: eip = 0x7c90120f in ntdll!DbgUiConnectToDbg; saved eip 0x7c951e40 called by frame at 0x190ffd4 Arglist at 0x190ffc8, args: Locals at 0x190ffc8, Previous frame's sp is 0x190ffd0 Saved registers: eip at 0x190ffcc (gdb) info threads * 2 thread 2316.0x93c 0x7c90120f in ntdll!DbgUiConnectToDbg () from /c/WINDOWS/system32/ntdll.dll 1 thread 2316.0xde0 0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll (gdb) thread 1 [Switching to thread 1 (thread 2316.0xde0)]#0 0x7c90e514 in ntdll!LdrAccessReso urce () from /c/WINDOWS/system32/ntdll.dll (gdb) backtrace #0 0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll #1 0x7c90df5a in ntdll!ZwWaitForSingleObject () from /c/WINDOWS/system32/ntdll.dll #2 0x7c8025db in WaitForSingleObjectEx () from /c/WINDOWS/system32/kernel32.dll #3 0x00000769 in ?? () #4 0x00000000 in ?? () (gdb) info frame Stack level 0, frame at 0x8297e8: eip = 0x7c90e514 in ntdll!LdrAccessResource; saved eip 0x7c90df5a called by frame at 0x8297ec Arglist at 0x8297e0, args: Locals at 0x8297e0, Previous frame's sp is 0x8297e8 Saved registers: eip at 0x8297e4 (gdb) info locals No symbol table info available. It looks like it's hung in some system call, trying to load a resource. Any more ideas? Troy > I have used the built-in zip facilities in Windows since the release of > Windows XP to unpack emacs and that has always worked fine for me. > > > > Francis > > > > *From:* [email protected] [mailto: > help-emacs-windows-bounces+f.j.wright<help-emacs-windows-bounces%2Bf.j.wright> > [email protected]] *On Behalf Of *Troy Daniels > *Sent:* Wednesday, March 17, 2010 3:37 AM > *To:* [email protected] > *Subject:* [h-e-w] Emacs failing to start > > > > I'm trying to get emacs to work on a laptop. I'm running Windows XP > Professional Version 2002 Service Pack 3, with a Pentium M 2.13 GHz > processor and 2 GB of ram. > > I have downloaded emacs-23.1-bin-i386.zip from > http://ftp.gnu.org/gnu/emacs/windows/emacs-23.1-bin-i386.zip. I have > cygwin installed, and updated a few minutes ago. I extracted the zip file > to ~/emacs/emacs-23.1. > > cd ~/emacs/emacs-23.1/bin > ./emacs -version > > works: > > $ ./emacs -version > GNU Emacs 23.1.1 > Copyright (C) 2009 Free Software Foundation, Inc. > GNU Emacs comes with ABSOLUTELY NO WARRANTY. > You may redistribute copies of Emacs > under the terms of the GNU General Public License. > For more information about these matters, see the file named COPYING. > > If I try to start emacs from a bash shell > > $ ./emacs > > it hangs. No window appears; I also do not get the "in-tty" version in the > bash window. The process shows up in the task manager, but does not use any > CPU. It uses about 3Mb of memory. > > $ ./runemacs.exe > > gives me a new prompt almost immediately, but no emacs window. An emacs > process does not show up in the task manager. > > I've downloaded the zip several times, with similar results. > > When I open the zip file with 7-Zip 4.65, it claims that the unpacked size > of the file is the same size as reported by ls for the disk file, so there > probably isn't a problem with the newlines being stripped. > > To check if it's a cygwin problem, I double clicked on emacs.exe and > runemacs.exe from Windows Explorer. emacs.exe gave me a typical windows > command window (like when you run a batch file), but no further output or > emacs windows. runemacs did not create any windows. > > C-c, C-z and C-g had no effect on a shell that was hung running emacs. I > had to kill the process from the Task Manager to get back to a prompt. > > $ ./emacs -nw > > also hangs in the same manner as ./emacs. > > cmdproxy and emacsclient from the same directory seem to work. > (Emacsclient obviously doesn't do much, since there is no emacs running a > server, but it prints an error message about no socket or alternate > editor.) hexl also appears to work. > > Does anybody have any idea what the problem might be? > > Troy >
