* Building Emacs-cvs on Cygwin
@ 2006-09-19 23:49 Angelo Graziosi
2006-09-20 3:29 ` Eli Zaretskii
0 siblings, 1 reply; 75+ messages in thread
From: Angelo Graziosi @ 2006-09-19 23:49 UTC (permalink / raw)
I often try to build emacs-cvs in this way:
>From Cygwin bash shell
----------------------------------------------------------------------
cd /tmp
cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/cvsroot/emacs co -P
emacs
cd emacs
mkdir -p .build .inst
cd .build
../configure --prefix=/usr/local/emacs-22.0.50
make bootstrap
make install prefix=/tmp/emacs/.inst/usr/local/emacs-22.0.50
cd /tmp/emacs/.inst
find usr/local/emacs-22.0.50 \! -type d | tar cjfT \
tmp/emacs-22.0.50-cvs.tar.bz2 -
----------------------------------------------------------------------
The last time that this methods has worked is with the CVS source of Emacs
downloaded Sep 04 2006 (and CVS Aug 15, 2006).
Now every time that I build, the build fails:
--------------------------------------------------------------------
....
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
Static heap usage: 10779888 of 12582912 bytes
66931 pure bytes used
mv -f emacs.exe bootstrap-emacs.exe
make[2]: Leaving directory `/tmp/emacs/.build/src'
(cd lisp; make -w bootstrap EMACS=../src/bootstrap-emacs.exe)
make[2]: Entering directory `/tmp/emacs/.build/lisp'
wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in
$subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/*
| */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
for file in $wins; do \
/tmp/emacs/lisp/../update-subdirs $file; \
done;
wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in
$subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/*
| */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
echo Directories: $wins; \
../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l
autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins
Directories: /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc
/tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp
/tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell
/tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international
/tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e
/tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play
/tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
Fatal error (6)/bin/sh: line 2: 3596 Aborted (core
dumped) ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l
autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins
make[2]: *** [autoloads] Error 134
make[2]: Leaving directory `/tmp/emacs/.build/lisp'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/tmp/emacs/.build'
make: *** [bootstrap] Error 2
--------------------------------------------------------------------
Any idea on what happened?
I have all Cygwin installed and updated on XP SP2. The same Cygwin DLL
1.5.21-2 was used at Sep 04 and Aug 15, 2006, nothing has basically
changed since then in Cygwin.
I have tried also with the exp. bash-3.1-8 and make.exe described in
http://cygwin.com/ml/cygwin/2006-09/msg00131.html but always with the same
results.
I have tried to use GDB (I am not an expert of GDB):
-------------------------------------------------------------
$ gdb --args ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte
-l autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f
batch-update-autoloads /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc
/tmp/emacs/lis
p/./calendar /tmp/emacs/lisp/./emacs-lisp /tmp/emacs/lisp/./emulation
/tmp/emac
s/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus
/tmp/emacs/lisp/./
international /tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail
/tmp/emacs/lisp
/./mh-e /tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete
/tmp/emacs/lisp/./play
/tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes
/tmp/emacs/lisp/./url
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
...
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
(gdb) r
Starting program: /tmp/emacs/src/bootstrap-emacs.exe -batch --no-site-file
--multibyte -l autoload --eval \(setq\ generated-autoload-file\
\"/tmp/emacs/lisp/loaddefs.el\"\) -f batch-update-autoloads
/tmp/emacs/lisp/. /tmp/emacs/lisp/./calc
/tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp
/tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus
/tmp/emacs/lisp/./international /tmp/emacs/lisp/./language
/tmp/emacs/lisp/./mail /tmp
/emacs/lisp/./mh-e /tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete
/tmp/emacs/lisp/./play /tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
[3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch
--no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads
/tmp/emacs/lisp/. /tmp/emacs/lisp/./calc /tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp
/tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell
/tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international /tmp/emacs/lisp/./language
/tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e /tmp/emacs/lisp/./net
/tmp/emacs/lisp/./obsolete /
tmp/emacs/lisp/./play /tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
$
-------------------------------------------------------------
and ps shows
S 4016 2308 4016 628 con 1003 01:37:14 /usr/bin/gdb
Any suggestion will be very appreciated.
Cheers,
Angelo.
^ permalink raw reply [flat|nested] 75+ messages in thread* Re: Building Emacs-cvs on Cygwin 2006-09-19 23:49 Building Emacs-cvs on Cygwin Angelo Graziosi @ 2006-09-20 3:29 ` Eli Zaretskii 2006-09-20 9:05 ` Angelo Graziosi 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-09-20 3:29 UTC (permalink / raw) Cc: emacs-devel > Date: Wed, 20 Sep 2006 01:49:56 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > I have tried to use GDB (I am not an expert of GDB): > ------------------------------------------------------------- > $ gdb --args ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte Please run this from the `src' directory, since it includes a .gdbinit file which will greatly help in debugging Emacs. > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > Copyright (C) 2006 Free Software Foundation, Inc. > ... > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ That is no good: your Emacs binary is somehow stripped, so it will be very hard to debug it. Please modify your build procedure so that Emacs is not stripped. > (gdb) r > Starting program: /tmp/emacs/src/bootstrap-emacs.exe -batch --no-site-file > --multibyte -l autoload --eval \(setq\ generated-autoload-file\ > \"/tmp/emacs/lisp/loaddefs.el\"\) -f batch-update-autoloads > /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc > /tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp > /tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus > /tmp/emacs/lisp/./international /tmp/emacs/lisp/./language > /tmp/emacs/lisp/./mail /tmp > /emacs/lisp/./mh-e /tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete > /tmp/emacs/lisp/./play /tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term > /tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url > > [3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch Why ``Stopped''? Did you type something to stop the job? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-20 3:29 ` Eli Zaretskii @ 2006-09-20 9:05 ` Angelo Graziosi 2006-09-20 21:08 ` Eli Zaretskii 2006-09-21 1:59 ` Richard Stallman 0 siblings, 2 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-09-20 9:05 UTC (permalink / raw) Cc: emacs-devel On Wed, 20 Sep 2006, Eli Zaretskii wrote: > > > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > > Copyright (C) 2006 Free Software Foundation, Inc. > > ... > > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think this refers to GDB (even with CFLAGS='-g' I obtain it, see below) > That is no good: your Emacs binary is somehow stripped, so it will be > very hard to debug it. Please modify your build procedure so that > Emacs is not stripped. > > > /tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url > > > > [3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch > > Why ``Stopped''? Did you type something to stop the job? > Absolutely : NO ! I have typed only 'r' (gdb) r Now there is what I have done (I have copy/pasted) following your suggestions: ========================================================================== $ cd emacs $ CFLAGS='-g' ./configure $ CFLAGS='-g' make bootstrap 2>&1 | tee ../build-emacs-cvs.log ... $ make[2]: Entering directory `/tmp/emacs/lisp' wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/* | */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \ for file in $wins; do \ /tmp/emacs/lisp/../update-subdirs $file; \ done; wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/* | */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \ echo Directories: $wins; \ ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file "/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins Directories: /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc /tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp /tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international /tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e /tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play /tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term /tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url Fatal error (6)/bin/sh: line 2: 1388 Aborted (core dumped) ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file "/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins make[2]: *** [autoloads] Error 134 make[2]: Leaving directory `/tmp/emacs/lisp' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/tmp/emacs' make: *** [bootstrap] Error 2 $ cd src $ gdb --args ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file "/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc /tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp /tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international /tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e /tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play /tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term /tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) ^^^^^^^^^^^^^^^^^^^^^^^^^^ DISPLAY = :0.0 TERM = xterm /tmp/emacs/src/.gdbinit:1089: Error in sourced command file: No struct type named Lisp_Symbol. (gdb) r Starting program: /tmp/emacs/src/bootstrap-emacs.exe -geometry 80x40+0+0 Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll [1]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file "/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc /tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp /tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international /tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e /tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play /tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term /tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url $ i.e. it exit (?) from GDB but: $ ps PID PPID PGID WINPID TTY UID STIME COMMAND I 2288 1 2288 2288 con 1003 10:07:16 /usr/bin/bash 3060 2288 3060 3076 con 1003 10:07:33 /usr/bin/sh 3088 3060 3060 3104 con 1003 10:07:33 /usr/X11R6/bin/xinit 3116 3088 3116 3136 con 1003 10:07:33 /usr/X11R6/bin/XWin 3304 3088 3304 3332 con 1003 10:07:41 /usr/bin/urxvt-X 3428 3304 3428 3448 0 1003 10:07:42 /usr/bin/bash 2616 2288 2616 2656 con 1003 10:14:38 /c/Programmi/Crimson Editor/cedt S 4068 3428 4068 1504 0 1003 10:46:39 /usr/bin/gdb 2712 1 2712 2712 con 1003 10:46:46 /tmp/emacs/src/bootstrap-emacs 4060 3428 4060 3616 0 1003 10:46:48 /usr/bin/ps ========================================================================== Note the 'no debugging symbols found'. Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-20 9:05 ` Angelo Graziosi @ 2006-09-20 21:08 ` Eli Zaretskii 2006-09-20 22:02 ` Andreas Schwab ` (2 more replies) 2006-09-21 1:59 ` Richard Stallman 1 sibling, 3 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-20 21:08 UTC (permalink / raw) Cc: emacs-devel > Date: Wed, 20 Sep 2006 11:05:54 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I think this refers to GDB No, I don't think so. > (even with CFLAGS='-g' I obtain it, see below) Maybe the binary gets stripped somehow, I don't know. Or maybe it's some problem with GCC/GDB in the Cygwin ports. Please try this in the Emacs `src' directory: gdb ./bootstrap-emacs.exe If it still says "no debugging symbols", you need to find out why is this happening, because it's impossible to debug a program without debugging symbols. > > > [3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch > > > > Why ``Stopped''? Did you type something to stop the job? > > > > Absolutely : NO ! > > I have typed only 'r' Then maybe there's another problem with the Cygwin GDB. Or maybe this is something else altogether. Note that this line: > Fatal error (6)/bin/sh: line 2: 1388 Aborted (core > dumped) seems to indicate that the program that crashed is /bin/sh, the ported Bash, not Emacs. Can you verify that it's the shell that crashes (e.g., by looking at the PID)? Another thing to try is downgrade to the previous version of Cygwin. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-20 21:08 ` Eli Zaretskii @ 2006-09-20 22:02 ` Andreas Schwab 2006-09-20 22:41 ` Building Emacs-cvs on Cygwin (Mystery!) Angelo Graziosi 2006-09-23 10:33 ` Building Emacs-cvs on Cygwin Angelo Graziosi 2 siblings, 0 replies; 75+ messages in thread From: Andreas Schwab @ 2006-09-20 22:02 UTC (permalink / raw) Cc: Angelo Graziosi, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Or maybe this is something else altogether. Note that this line: > >> Fatal error (6)/bin/sh: line 2: 1388 Aborted (core >> dumped) > > seems to indicate that the program that crashed is /bin/sh, No, it doesn't. The shell just tells you that process 1388 has died of SIGABRT (and you stripped the part that contains the command that crashed). Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (Mystery!) 2006-09-20 21:08 ` Eli Zaretskii 2006-09-20 22:02 ` Andreas Schwab @ 2006-09-20 22:41 ` Angelo Graziosi 2006-09-21 3:31 ` Eli Zaretskii 2006-09-23 10:33 ` Building Emacs-cvs on Cygwin Angelo Graziosi 2 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-20 22:41 UTC (permalink / raw) Cc: emacs-devel Hi Eli, after my last replay (http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg00829.html) I have deleted the Emacs build directory, re-unpacked the same CVS source (I make a tar.bz2 after every cvs download) and newly: ./configure make bootstrap and this time the build has (mysteriously) passed the critical point until the end ! But the build is unstable: after a few second Emacs segment fault. Now I have updated from CVS and a new build is running. For the moment I can't try your last suggestions. Regarding the Cygwin downgrade, I remeber that also with previous version of Cygwin and snapshot there were similar problem. Only with the CVS source Aug 15 ans Sep 04 I was able to complete the build and they works. Cheers, Angelo. > Please try this in the Emacs `src' directory: > > gdb ./bootstrap-emacs.exe > > If it still says "no debugging symbols", you need to find out why is > this happening, because it's impossible to debug a program without > debugging symbols. > > > > > [3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch > > > > > > Why ``Stopped''? Did you type something to stop the job? > > > > > > > Absolutely : NO ! > > > > I have typed only 'r' > > Then maybe there's another problem with the Cygwin GDB. > > Or maybe this is something else altogether. Note that this line: > > > Fatal error (6)/bin/sh: line 2: 1388 Aborted (core > > dumped) > > seems to indicate that the program that crashed is /bin/sh, the ported > Bash, not Emacs. Can you verify that it's the shell that crashes > (e.g., by looking at the PID)? > > Another thing to try is downgrade to the previous version of Cygwin. > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (Mystery!) 2006-09-20 22:41 ` Building Emacs-cvs on Cygwin (Mystery!) Angelo Graziosi @ 2006-09-21 3:31 ` Eli Zaretskii 2006-09-21 22:20 ` Angelo Graziosi 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-09-21 3:31 UTC (permalink / raw) Cc: emacs-devel > Date: Thu, 21 Sep 2006 00:41:25 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > ./configure > make bootstrap > > and this time the build has (mysteriously) passed the critical point until > the end ! > > But the build is unstable: after a few second Emacs segment fault. Does this happen even if you leave Emacs to run without doing anything in Emacs? Or does it happen only if you do your normal work in Emacs? In any case, can you run Emacs under GDB and show the backtrace when it crashes? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (Mystery!) 2006-09-21 3:31 ` Eli Zaretskii @ 2006-09-21 22:20 ` Angelo Graziosi 2006-09-22 13:19 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-21 22:20 UTC (permalink / raw) Cc: emacs-devel On Thu, 21 Sep 2006, Eli Zaretskii wrote: > > Does this happen even if you leave Emacs to run without doing anything > in Emacs? Yes it does, in less then one minute. > > In any case, can you run Emacs under GDB and show the backtrace when > it crashes? > Yes I have tried with the following results (copy/pasted): ------------------------------------------------------------------- Angelo@homepc /usr/local/emacs-22.0.50/bin $ ./emacs (after a few seconds that it started and displyed some files) Fatal error (11) <== in some cases Segmentation fault <== always Angelo@homepc /usr/local/emacs-22.0.50/bin $ Angelo@homepc /usr/local/emacs-22.0.50/bin $ ls -lrt total 31292 -rwxr-xr-x 1 Angelo Administrators 100892 Sep 21 16:35 etags.exe -rwxr-xr-x 1 Angelo Administrators 103360 Sep 21 16:35 ctags.exe -rwxr-xr-x 1 Angelo Administrators 25681 Sep 21 16:35 emacsclient.exe -rwxr-xr-x 1 Angelo Administrators 18983 Sep 21 16:35 b2m.exe -rwxr-xr-x 1 Angelo Administrators 52222 Sep 21 16:35 ebrowse.exe -rwxr-xr-x 1 Angelo Administrators 4055 Sep 21 16:35 rcs-checkin -rwxr-xr-x 1 Angelo Administrators 7204 Sep 21 16:35 grep-changelog -rwxr-xr-x 2 Angelo Administrators 15858176 Sep 21 16:35 emacs.exe -rwxr-xr-x 2 Angelo Administrators 15858176 Sep 21 16:35 emacs-22.0.50.exe Angelo@homepc /usr/local/emacs-22.0.50/bin $ gdb ./emacs GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) (gdb) r Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll [1]+ Stopped gdb ./emacs Angelo@homepc /usr/local/emacs-22.0.50/bin Angelo@homepc /usr/local/emacs-22.0.50/bin $ ps PID PPID PGID WINPID TTY UID STIME COMMAND I 2268 1 2268 2268 con 1003 10:09:56 /usr/bin/bash 3036 2268 3036 3052 con 1003 10:10:10 /usr/bin/sh 3068 3036 3036 3084 con 1003 10:10:11 /usr/X11R6/bin/xinit 3096 3068 3096 3112 con 1003 10:10:11 /usr/X11R6/bin/XWin 3284 3068 3284 3312 con 1003 10:10:19 /usr/bin/urxvt-X 3404 3284 3404 3424 0 1003 10:10:21 /usr/bin/bash S 2144 3404 2144 2036 0 1003 17:09:38 /usr/bin/gdb 1812 1 1812 1812 con 1003 17:09:44 /usr/local/emacs-22.0.50/bin/emacs 3892 3404 3892 3104 0 1003 17:12:17 /usr/bin/ps ------------------------------------------------------------------- As you see, the same behaviour of previous posts. Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (Mystery!) 2006-09-21 22:20 ` Angelo Graziosi @ 2006-09-22 13:19 ` Eli Zaretskii 2006-09-22 23:08 ` Angelo Graziosi ` (2 more replies) 0 siblings, 3 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-22 13:19 UTC (permalink / raw) Cc: emacs-devel > Date: Fri, 22 Sep 2006 00:20:43 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) We need to solve this ``no debugging symbols found'' problem. Can you please post the transcript of the entire configure+build procedure, or (better) look there for the command that stripped the symbols from the binary? The ``normal'' build should invoke GCC with the -g option, and should NOT use the -s option to GCC or the linker in the command that links temacs.exe. This should produce temacs.exe with debugging symbols, and then dumping emacs.exe should produce emacs.exe with debugging symbols. What happens if you type "gdb ./temacs.exe", does it also say ``no debugging symbols found''? > (gdb) r "r -Q" is better, as it doesn't load any init files. > Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe > Loaded symbols for /c/WINDOWS/system32/ntdll.dll > Loaded symbols for /c/WINDOWS/system32/kernel32.dll > Loaded symbols for /usr/X11R6/bin/cygICE-6.dll > Loaded symbols for /usr/bin/cygwin1.dll > Loaded symbols for /c/WINDOWS/system32/advapi32.dll > Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll > Loaded symbols for /usr/X11R6/bin/cygSM-6.dll > Loaded symbols for /usr/X11R6/bin/cygX11-6.dll > Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll > Loaded symbols for /usr/X11R6/bin/cygXext-6.dll > Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll > Loaded symbols for /usr/X11R6/bin/cygXt-6.dll > Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll > Loaded symbols for /usr/bin/cygncurses-8.dll > Loaded symbols for /usr/bin/cygjpeg-62.dll > Loaded symbols for /usr/bin/cygpng12.dll > Loaded symbols for /usr/bin/cygz.dll > Loaded symbols for /usr/bin/cygtiff-5.dll > Loaded symbols for /usr/bin/cygungif-4.dll > > [1]+ Stopped gdb ./emacs Can you type "fg" at this point, to get back into GDB? If that works, can you type "bt" inside GDB and get a meaningful traceback? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (Mystery!) 2006-09-22 13:19 ` Eli Zaretskii @ 2006-09-22 23:08 ` Angelo Graziosi 2006-09-22 23:22 ` Angelo Graziosi 2006-09-24 13:02 ` Angelo Graziosi 2 siblings, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-09-22 23:08 UTC (permalink / raw) Cc: emacs-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 3205 bytes --] On Fri, 22 Sep 2006, Eli Zaretskii wrote: > > We need to solve this ``no debugging symbols found'' problem. Can you > please post the transcript of the entire configure+build procedure, or > (better) look there for the command that stripped the symbols from the > binary? I have looked but found anything, so I have attached Build_Emacs-CVS.tar.bz2 which contains : build-emacs-cvs.sh build-emacs-cvs.log .emacs-cvs The first is the script to build Emacs-CVS and that produces the .log file of the building (configure included), the last is the initialization file (.emacs). > > The ``normal'' build should invoke GCC with the -g option, and should > NOT use the -s option to GCC or the linker in the command that links > temacs.exe. This should produce temacs.exe with debugging symbols, > and then dumping emacs.exe should produce emacs.exe with debugging > symbols. > > What happens if you type "gdb ./temacs.exe", does it also say ``no > debugging symbols found''? I will try this at the next build (tomorrow), I have deleted the building tree. > > > (gdb) r > > "r -Q" is better, as it doesn't load any init files. > > > Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe ... > > Loaded symbols for /usr/bin/cygtiff-5.dll > > Loaded symbols for /usr/bin/cygungif-4.dll > > > > [1]+ Stopped gdb ./emacs > > Can you type "fg" at this point, to get back into GDB? > Yes (oh yes, fg!); this is the result ------------------------------------------------------- [1]+ Stopped gdb ./emacs.exe Angelo@homepc /usr/local/emacs-22.0.50/bin $ fg gdb ./emacs.exe ---Type <return> to continue, or q <return> to quit--- warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] ---Type <return> to continue, or q <return> to quit--- ------------------------------------------------------- A this point Emacs starts and for the moment it seems to works. > If that works, can you type "bt" inside GDB and get a meaningful > traceback? > I think NO, I haven't any GDB prompt. In any case I have typed 'bt' without results: ----------------------------------------------------- ... warning: NOD32 protected [RSVP TCP Service Provider] ---Type <return> to continue, or q <return> to quit--- bt ----------------------------------------------------- I can continue to type <Return> with the only result to add lines. After a few minutes that anything happened, I have decided to close Emacs (click on 'x' button of the window): -------------------------------------------------------- ---Type <return> to continue, or q <return> to quit--- bt Program exited normally. (gdb) (gdb) bt No stack. (gdb) No stack. (gdb) No stack. (gdb) bt No stack. (gdb) -------------------------------------------------------- After this I have repeated using (gdb) -r so that also the init file is loaded. For the moment same behaviour without seg. fault. I will observe for a longer time the behaviour of Emacs under GDB. Thanks, Angelo. [-- Attachment #2: Type: APPLICATION/octet-stream, Size: 43196 bytes --] [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (Mystery!) 2006-09-22 13:19 ` Eli Zaretskii 2006-09-22 23:08 ` Angelo Graziosi @ 2006-09-22 23:22 ` Angelo Graziosi 2006-09-24 13:02 ` Angelo Graziosi 2 siblings, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-09-22 23:22 UTC (permalink / raw) Cc: emacs-devel On Fri, 22 Sep 2006, Eli Zaretskii wrote: > > If that works, can you type "bt" inside GDB and get a meaningful > traceback? > I was too fast in my last replay: >> After this I have repeated using >> (gdb) -r >> >> >> so that also the init file is loaded. For the moment same behaviour >> without seg. fault. Wrong ! When I clicked on Emacs window (thinking it was running) I found: ----------------------------------------------------------------- ... ---Type <return> to continue, or q <return> to quit--- q Program received signal SIGSEGV, Segmentation fault. 0x200f201c in mark_object () (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) q The program is running. Exit anyway? (y or n) n Not confirmed. (gdb) bt #0 0x200f201c in mark_object () #1 0x200f28ef in Fgarbage_collect () #2 0x201063d3 in Feval () #3 0x201051f5 in internal_condition_case_1 () #4 0x200a47a2 in menu_item_eval_property () #5 0x200b0d4e in get_keyelt () #6 0x200b13a3 in access_keymap () #7 0x200a5496 in tool_bar_items () #8 0x2001d51f in update_tool_bar () #9 0x2002bc8f in prepare_menu_bars () #10 0x2002c8ec in redisplay_internal () #11 0x2002d08a in redisplay_preserve_echo_area () #12 0x200a7aec in detect_input_pending_run_timers () #13 0x2013a0f5 in wait_reading_process_output () #14 0x200a8e40 in read_char () #15 0x200ab88d in read_key_sequence () #16 0x200ad3d1 in command_loop_1 () #17 0x2010542f in internal_condition_case () #18 0x200a0a8e in command_loop_2 () #19 0x201050ef in internal_catch () #20 0x200a08a3 in command_loop () #21 0x200a0944 in recursive_edit_1 () #22 0x200a0a20 in Frecursive_edit () ---Type <return> to continue, or q <return> to quit--- #23 0x2009fd9d in main () (gdb) ----------------------------------------------------------------- Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (Mystery!) 2006-09-22 13:19 ` Eli Zaretskii 2006-09-22 23:08 ` Angelo Graziosi 2006-09-22 23:22 ` Angelo Graziosi @ 2006-09-24 13:02 ` Angelo Graziosi 2 siblings, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-09-24 13:02 UTC (permalink / raw) Cc: emacs-devel For the sake of completeness you asked me: On Fri, 22 Sep 2006, Eli Zaretskii wrote: > What happens if you type "gdb ./temacs.exe", does it also say ``no > debugging symbols found''? > The result: ----------------------------- $ gdb ./temacs.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DISPLAY = :0.0 TERM = xterm /tmp/emacs/.build/src/.gdbinit:1: Error in sourced command file: <===(?) /tmp/emacs/src/.gdbinit:1089: Error in sourced command file: <===(?) No struct type named Lisp_Symbol. <===(?) (gdb) r Starting program: /tmp/emacs/.build/src/temacs.exe -geometry 80x40+0+0 Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll [1]+ Stopped gdb ./temacs.exe user@pcname /tmp/emacs/.build/src $ fg gdb ./temacs.exe ---Type <return> to continue, or q <return> to quit--- warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] ---Type <return> to continue, or q <return> to quit--- ----------------------------- At this point it seems to hang and I must kill GDB. But if I use "(gdb) start" then: ---------------------------------- ... DISPLAY = :0.0 TERM = xterm /tmp/emacs/.build/src/.gdbinit:1: Error in sourced command file: /tmp/emacs/src/.gdbinit:1089: Error in sourced command file: No struct type named Lisp_Symbol. (gdb) start Breakpoint 1 at 0x2009f37b Starting program: /tmp/emacs/.build/src/temacs.exe -geometry 80x40+0+0 ... Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll [1]+ Stopped gdb ./temacs.exe $ fg gdb ./temacs.exe ---Type <return> to continue, or q <return> to quit--- 0x2009f37b in main () (gdb) bt #0 0x2009f37b in main () (gdb) ---------------------------------- Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-20 21:08 ` Eli Zaretskii 2006-09-20 22:02 ` Andreas Schwab 2006-09-20 22:41 ` Building Emacs-cvs on Cygwin (Mystery!) Angelo Graziosi @ 2006-09-23 10:33 ` Angelo Graziosi 2006-09-23 15:15 ` Eli Zaretskii 2006-09-24 2:10 ` Richard Stallman 2 siblings, 2 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-09-23 10:33 UTC (permalink / raw) Cc: emacs-devel On Thu, 21 Sep 2006, Eli Zaretskii wrote: > > Date: Wed, 20 Sep 2006 11:05:54 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > > > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > I think this refers to GDB > > No, I don't think so. > On Wed, 20 Sep 2006 , Richard Stallman wrote: > It refers to the program you are debugging. GDB has already tried to > read that executable, and failed. > > /tmp/emacs/src/.gdbinit:1089: Error in sourced command file: > No struct type named Lisp_Symbol. > > Further proof of the same problem. Considere the following examples: --------------------------------------------------------- $ cat hello.c #include <stdio.h> int main() { printf("Hello, World!"); return 0; } $ gcc -g hello.c -o hello ^^^^^ $ gdb ./hello.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar welcome to change it and/or distribute copies of it under certain condition Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) --------------------------------------------------------- --------------------------------------------------------- $ cat hello.F program hello implicit none write(*,*) 'Hello!' end $ g77 -g hello.F -o hello ^^^^^ $ gdb ./hello.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) --------------------------------------------------------- Or I have missed something or there is something wrong in the above if yours conclusions are correct. Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-23 10:33 ` Building Emacs-cvs on Cygwin Angelo Graziosi @ 2006-09-23 15:15 ` Eli Zaretskii 2006-09-23 16:49 ` Angelo Graziosi 2006-09-24 2:10 ` Richard Stallman 1 sibling, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-09-23 15:15 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 23 Sep 2006 12:33:23 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > Considere the following examples: > > --------------------------------------------------------- > $ cat hello.c > #include <stdio.h> > > int main() > { > printf("Hello, World!"); > return 0; > } > > $ gcc -g hello.c -o hello > ^^^^^ > > $ gdb ./hello.exe > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > ar > welcome to change it and/or distribute copies of it under certain > condition > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (gdb) How about the following compilation command--does it also cause GDB to complain about debugging symbols? gcc -gdwarf-2 -g3 hello.c -o hello Also, if you type the following two commands after starting GDB, what does GDB say? (gdb) start (gdb) info source ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-23 15:15 ` Eli Zaretskii @ 2006-09-23 16:49 ` Angelo Graziosi 2006-09-23 19:17 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-23 16:49 UTC (permalink / raw) Cc: emacs-devel On Sat, 23 Sep 2006, Eli Zaretskii wrote: > > Date: Sat, 23 Sep 2006 12:33:23 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > cc: emacs-devel@gnu.org > > > > Considere the following examples: > > > > --------------------------------------------------------- > > $ cat hello.c > > #include <stdio.h> > > > > int main() > > { > > printf("Hello, World!"); > > return 0; > > } > > > > $ gcc -g hello.c -o hello > > ^^^^^ > > > > $ gdb ./hello.exe > > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > > Copyright (C) 2006 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > > ar > > welcome to change it and/or distribute copies of it under certain > > condition > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. > > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > (gdb) > > How about the following compilation command--does it also cause GDB to > complain about debugging symbols? > > gcc -gdwarf-2 -g3 hello.c -o hello NO! I does NOT!!! > > Also, if you type the following two commands after starting GDB, what > does GDB say? > > (gdb) start > (gdb) info source > I have copy/pasted the result: ----------------------------------------------------------------- $ gcc -gdwarf-2 -g3 hello.c -o hello $ gdb ./hello.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... <== note this ====| (gdb) start Breakpoint 1 at 0x401075: file hello.c, line 4. Starting program: /tmp/hello.exe Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll main () at hello.c:4 4 { (gdb) info source Current source file is hello.c Compilation directory is /tmp/ Located in /tmp/hello.c Contains 7 lines. Source language is c. Compiled with stabs debugging format. Does not include preprocessor macro info. (gdb) ----------------------------------------------------------------- Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-23 16:49 ` Angelo Graziosi @ 2006-09-23 19:17 ` Eli Zaretskii 2006-09-23 21:19 ` Angelo Graziosi 2006-09-24 22:46 ` Angelo Graziosi 0 siblings, 2 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-23 19:17 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 23 Sep 2006 18:49:59 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > > > How about the following compilation command--does it also cause GDB to > > complain about debugging symbols? > > > > gcc -gdwarf-2 -g3 hello.c -o hello > > NO! I does NOT!!! Good! > (gdb) info source > Current source file is hello.c > Compilation directory is /tmp/ > Located in /tmp/hello.c > Contains 7 lines. > Source language is c. > Compiled with stabs debugging format. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This doesn't look right: it should have told ``with DWARF 2 debugging format''. That's what the -gdwarf-2 switch is about. I wonder what the heck is going on here. Can you please add -v to the compilation command line, like this: gcc -v -gdwarf-2 -g3 hello.c -o hello and post here everything that is displayed by the compiler? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-23 19:17 ` Eli Zaretskii @ 2006-09-23 21:19 ` Angelo Graziosi 2006-09-24 7:41 ` Eli Zaretskii 2006-09-24 22:46 ` Angelo Graziosi 1 sibling, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-23 21:19 UTC (permalink / raw) Cc: emacs-devel On Sat, 23 Sep 2006, Eli Zaretskii wrote: > > Source language is c. > > Compiled with stabs debugging format. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This doesn't look right: it should have told ``with DWARF 2 debugging > format''. That's what the -gdwarf-2 switch is about. I wonder what > the heck is going on here. > > Can you please add -v to the compilation command line, like this: > > gcc -v -gdwarf-2 -g3 hello.c -o hello > > and post here everything that is displayed by the compiler? > This is the output: ---------------------------------------------------------------- $ gcc -v -gdwarf-2 -g3 hello.c -o hello Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.new4/gcc-3.4.4-2/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -dD -D__CYGWIN32__ -D__CYGW IN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../ ../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../.. /i686-pc-cygwin/lib/../../include/w32api hello.c -quiet -dumpbase hello.c -mtune=pentiumpro -auxbase hello-gdwarf-2 -g3 -version -o /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPqN.s ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/i686-pc-cygwin/3.4.4/include /usr/include /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api End of search list. GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) (i686-pc-cygwin ) compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe -o /c/D OCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPq N.s /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic --dll-search-prefix=cy g -o hello.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o -L/usr/lib/gcc/ i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc $ ---------------------------------------------------------------- Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-23 21:19 ` Angelo Graziosi @ 2006-09-24 7:41 ` Eli Zaretskii 0 siblings, 0 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-24 7:41 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 23 Sep 2006 23:19:27 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > > > Can you please add -v to the compilation command line, like this: > > > > gcc -v -gdwarf-2 -g3 hello.c -o hello > > > > and post here everything that is displayed by the compiler? > > > > > This is the output: > ---------------------------------------------------------------- > $ gcc -v -gdwarf-2 -g3 hello.c -o hello > Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs > Configured with: /usr/build/package/orig/test.new4/gcc-3.4.4-2/configure > --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib > --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info > --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls > --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj > --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug > --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry > --enable-sjlj-exceptions > --enable-hash-synchronization --enable-libstdcxx-debug > Thread model: posix > gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -dD -D__CYGWIN32__ > -D__CYGW > IN__ -Dunix -D__unix__ -D__unix -idirafter > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../ > ../../../include/w32api -idirafter > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../.. > /i686-pc-cygwin/lib/../../include/w32api hello.c -quiet -dumpbase hello.c > -mtune=pentiumpro -auxbase hello-gdwarf-2 -g3 -version -o > /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPqN.s > ignoring nonexistent directory > "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include" > ignoring duplicate directory > "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include > /usr/include > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api > End of search list. > GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd > 0.125) (i686-pc-cygwin > ) > compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using > dmd 0.125). > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe > -o /c/D > OCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o > /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPq > N.s > /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic > --dll-search-prefix=cy > g -o hello.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o > -L/usr/lib/gcc/ > i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 > -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o -lgcc > -lcygwin > -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc Thanks. And after all this, "gdb ./hello.exe" _still_ says that hello.c was compiled with stabs debugging info? If so, please post this information to the Cygwin mailing list and ask for the experts there to comment on these two problems: (1) that "gcc -g" produces a program for which GDB says that it find no debugging symbols, and (2) that "gcc -gdwarf-2" produces a program for which GDB says that it was compiled with stabs debugging format, not DWARF 2 debugging format. There are hints in what GCC displays which suggest that perhaps DWARF 2 is not supported at all by the Cygwin port of GCC. (This sounds like a side issue for the original problem, but I think we need to solve this first, before we continue debugging the crash. DWARF 2 debug info is much more powerful than stabs, especially when looking at function call stack backtraces, so I'd like to find a way to build Emacs with DWARF 2 debug info. And, on top of that, the strange behavior of GCC/GDB wrt debugging symbols is something that might mean we misunderstand some important aspect of what is going on.) ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-23 19:17 ` Eli Zaretskii 2006-09-23 21:19 ` Angelo Graziosi @ 2006-09-24 22:46 ` Angelo Graziosi 2006-09-25 3:26 ` Eli Zaretskii 1 sibling, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-24 22:46 UTC (permalink / raw) Cc: emacs-devel On Sat, 23 Sep 2006, Eli Zaretskii wrote: > > Date: Sat, 23 Sep 2006 18:49:59 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > cc: emacs-devel@gnu.org > > > > > > How about the following compilation command--does it also cause GDB to > > > complain about debugging symbols? > > > > > > gcc -gdwarf-2 -g3 hello.c -o hello > > > > NO! I does NOT!!! > > Good! > > > (gdb) info source > > Current source file is hello.c > > Compilation directory is /tmp/ > > Located in /tmp/hello.c > > Contains 7 lines. > > Source language is c. > > Compiled with stabs debugging format. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This doesn't look right: it should have told ``with DWARF 2 debugging > format''. That's what the -gdwarf-2 switch is about. I wonder what > the heck is going on here. > > Can you please add -v to the compilation command line, like this: > > gcc -v -gdwarf-2 -g3 hello.c -o hello > > and post here everything that is displayed by the compiler? > Following this thread http://cygwin.com/ml/cygwin/2006-06/msg00855.html, I have added -ggdb with the following result: -------------------------------------------- $ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.new4/gcc-3.4.4-2/configure --verbo se --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexe cdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languag es=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --en able-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-aw t --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thread s=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -dD -D__CYGWIN32__ -D__CYGW IN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../ ../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../.. /i686-pc-cygwin/lib/../../include/w32api hello.c -quiet -dumpbase hello.c -mtune =pentiumpro -auxbase hello-ggdb -gdwarf-2 -g3 -version -o /c/DOCUME~1/Angelo/IMP OST~1/Temp/ccNuDw40.s ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i6 86-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686 -pc-cygwin/lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/i686-pc-cygwin/3.4.4/include /usr/include /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api End of search list. GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) (i686-pc-cygwin ) compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd 0. 125). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe -o /c/D OCUME~1/Angelo/IMPOST~1/Temp/ccGvKaO4.o /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccNuDw4 0.s /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic --dll-search-prefix=cy g -o hello.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o -L/usr/lib/gcc/ i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc- cygwin/3.4.4/../../.. /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccGvKaO4.o -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc $ gdb ./hello.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) start Breakpoint 1 at 0x401075: file hello.c, line 4. Starting program: /tmp/hello.exe Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll main () at hello.c:4 4 { (gdb) info source Current source file is hello.c Compilation directory is /tmp Located in /tmp/hello.c Contains 7 lines. Source language is c. Compiled with DWARF 2 debugging format. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Includes preprocessor macro info. (gdb) -------------------------------------------- Now it says 'Compiled with DWARF 2 debugging format.' !!! Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-24 22:46 ` Angelo Graziosi @ 2006-09-25 3:26 ` Eli Zaretskii 2006-09-25 12:56 ` Angelo Graziosi 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-09-25 3:26 UTC (permalink / raw) Cc: emacs-devel > Date: Mon, 25 Sep 2006 00:46:08 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > Following this thread http://cygwin.com/ml/cygwin/2006-06/msg00855.html, I > have added -ggdb with the following result: Good! Although -gdwarf-2 _should_ have produced the same effect. > $ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello Do you get the same effect with the following command? gcc -v -ggdb -g3 hello.c -o hello In any case, please reconfigure Emacs to use the switches that produce DWARF 2 debug info, and rebuild Emacs. The file INSTALL tells how to do that (search for "CFLAGS"). Note that you will need to use these switches both in CFLAGS and in LDFLAGS. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-25 3:26 ` Eli Zaretskii @ 2006-09-25 12:56 ` Angelo Graziosi 2006-09-25 19:57 ` Eli Zaretskii 2006-09-25 20:42 ` Kim F. Storm 0 siblings, 2 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-09-25 12:56 UTC (permalink / raw) Cc: emacs-devel On Mon, 25 Sep 2006, Eli Zaretskii wrote: > > Date: Mon, 25 Sep 2006 00:46:08 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > > > Following this thread http://cygwin.com/ml/cygwin/2006-06/msg00855.html, I > > have added -ggdb with the following result: > > Good! Although -gdwarf-2 _should_ have produced the same effect. > > > $ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello > > Do you get the same effect with the following command? > > gcc -v -ggdb -g3 hello.c -o hello NO ! It says "Compiled with stabs debugging format." > > In any case, please reconfigure Emacs to use the switches that produce > DWARF 2 debug info, and rebuild Emacs. The file INSTALL tells how to > do that (search for "CFLAGS"). Note that you will need to use these > switches both in CFLAGS and in LDFLAGS. > DONE! with the following result. I have adapted the build script: ------------------------------------------------ ... base_dir="${PWD_DIR}" source_dir="${base_dir}/emacs" build_dir="${source_dir}/.build" dest_dir="${source_dir}/.inst" prefix_dir_name="usr/local/emacs-${rel}" prefix_dir="/${prefix_dir_name}" cd ${base_dir} # echo "" # echo "Unpacking the source..." # tar -xjf ${PKG_DIR}/emacs-${rel}-cvs-src.tar.bz2 mkdir -p ${dest_dir} ${build_dir} cd ${build_dir} echo "" echo "Configuring..." LDFLAGS='-ggdb -gdwarf-2 -g3 -O2' \ CFLAGS='-ggdb -gdwarf-2 -g3 -O2' \ ../configure --prefix=${prefix_dir} echo "" echo "Making the bootstrap..." make bootstrap make install prefix=${dest_dir}/${prefix_dir_name} echo "" echo "Making the binary package..." cd ${dest_dir} find ${prefix_dir_name} \! -type d | \ tar cjfT ${base_dir}/emacs-${rel}-cvs.tar.bz2 - ------------------------------------------------ The first thing to say is that there is an 'Abort' when 'make install...': --------------------------------------------------------------------------- Compressing *.el ... chmod -R a+r /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim make[1]: Leaving directory `/tmp/emacs/.build/leim' cd lib-src; make maybe-blessmail \ MAKE='make' archlibdir='/tmp/emacs/.inst/usr/local/emacs-22.0.50/libexec/emacs/22.0.50/i686-pc-cygwin' make[1]: Entering directory `/tmp/emacs/.build/lib-src' ../src/emacs -batch -l /tmp/emacs/lib-src/../lisp/mail/blessmail.el Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped) make[1]: Leaving directory `/tmp/emacs/.build/lib-src' make: *** [blessmail] Error 2 Making the binary package... --------------------------------------------------------------------------- I have never got this until now, usually I have got: ------------------------------------------------------- Compressing *.el ... chmod -R a+r /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim make[1]: Leaving directory `/tmp/emacs/.build/leim' cd lib-src; make maybe-blessmail \ MAKE='make' archlibdir='/tmp/emacs/.inst/usr/local/emacs-22.0.50/libexec/emacs/22.0.50/i686-pc-cygwin' make[1]: Entering directory `/tmp/emacs/.build/lib-src' ../src/emacs -batch -l /tmp/emacs/lib-src/../lisp/mail/blessmail.el Wrote /tmp/emacs/.build/lib-src/blessmail chmod +x blessmail Assuming /usr/spool/mail is really the mail spool directory, you should run lib-src/blessmail /tmp/emacs/.inst/usr/local/emacs-22.0.50/libexec/emacs/22.0.50/i686-pc-cygwin/movemail.exe as root, to give movemail.exe appropriate permissions. Do that after running make install. make[1]: Leaving directory `/tmp/emacs/.build/lib-src' Making the binary package... ------------------------------------------------------- I have verifyed that now Emacs is 'Compiled with DWARF 2 debugging format.' After the build was completed and the binary package result installed: ---------------------------------------------------------------------- cd /usr/local/emacs-22.0.50/bin $ ./emacs Fatal error (6)Aborted (core dumped) $ cat emacs.exe.stackdump Stack trace: Frame Function Args 0022A8F8 7C802532 (00000594, 0000EA60, 000000A4, 0022A940) 0022AA18 61096A1C (00000000, 00000000, 00000000, 00000000) 0022AB08 6109459B (00000000, 0022AC30, 0022ABF8, 0022AAD0) 0022AB68 61094A7B (0022AB80, 00000000, 00000094, 200D3DA9) 0022AC28 61094C32 (00000D28, 00000006, 202D9801, 0022CE64) 0022AC48 61092068 (00000006, 60030000, 0022AD78, 61096ADC) 0022AD38 61017B80 (00000594, 0000EA60, 000000A4, 0022AD80) 0022AE58 61096ADC (00000000, 7C923E62, 00000208, 0022B23C) 0022AF48 6109459B (00000000, 0000021A, 00000000, 719DA6AF) 0022AFA8 61094A7B (0022AFC0, 00000000, 00000094, 0022B008) 0022B068 61094C32 (00000D28, 00000006, 0022B098, 2014D9D2) 0022B078 61092068 (00000000, 20690000, 218D0878, 202D0F20) 0022B098 2014D9D2 (206A0858, 218D0878, 00000E80, 0022B09C) 0022B0D8 2014E5C1 (FFFDD000, 00000000, 00000000, 00000000) 0022B148 2014CF2F (00003018, 0022B3A0, 0022B178, 2014D63D) 0022B158 200EFF1C (00003018, 00000000, 00000000, 71A116A3) End of stack trace (more stack frames may be present) ---------------------------------------------------------------------- Then I tried this: ---------------------------------------------------------------------- $ gdb ./emacs GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) r Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] [1]+ Stopped gdb ./emacs $ fg gdb ./emacs ---Type <return> to continue, or q <return> to quit--- --------------------------------------------------------- after a few seconds: ---------------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 5509 MARK_INTERVAL_TREE (ptr->intervals); (gdb) bt #0 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 #1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 #2 0x201064f3 in Feval (form=570000829) at /tmp/emacs/src/eval.c:2216 #3 0x20105315 in internal_condition_case_1 (bfun=0x20106450 <Feval>, arg=570000829, handlers=539914913, hfun=0x200a4710 <menu_item_eval_property_1>) at /tmp/emacs/src/eval.c:1525 #4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217) at /tmp/emacs/src/keyboard.c:7270 #5 0x200b0d4e in get_keyelt (object=540146505, autoload=1) at /tmp/emacs/src/keymap.c:829 #6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2, noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655 #7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b658) at /tmp/emacs/src/keyboard.c:7732 #8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0) at /tmp/emacs/src/xdisp.c:9414 #9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098 #10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217) at /tmp/emacs/src/xdisp.c:10935 #11 0x2002d057 in redisplay_preserve_echo_area (from_where=8) at /tmp/emacs/src/xdisp.c:11541 #12 0x200a7aec in detect_input_pending_run_timers (do_display=1) at /tmp/emacs/src/keyboard.c:10061 ---Type <return> to continue, or q <return> to quit--- #13 0x2013a265 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4665 #14 0x20009802 in sit_for (timeout=30, reading=1, do_display=1) at /tmp/emacs/src/dispnew.c:6548 #15 0x200a9590 in read_char (commandflag=1, nmaps=2, maps=0x22c710, prev_event=539858945, used_mouse_menu=0x22c758, end_time=0x0) at /tmp/emacs/src/keyboard.c:2865 #16 0x200ab88d in read_key_sequence (keybuf=0x22c8b0, bufsize=30, prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956 #17 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601 #18 0x2010554f in internal_condition_case (bfun=0x200ad220 <command_loop_1>, handlers=539914913, hfun=0x200a6c80 <cmd_error>) at /tmp/emacs/src/eval.c:1477 #19 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326 #20 0x2010520f in internal_catch (tag=1569454217, func=0x200a0a60 <command_loop_2>, arg=539858945) at /tmp/emacs/src/eval.c:1218 #21 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305 #22 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003 #23 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064 #24 0x2009fd9d in main (argc=1, argv=0x202ce8c0) at /tmp/emacs/src/emacs.c:1794 (gdb) ---------------------------------------------------------------------- Then I have retried using 'r -Q': --------------------------------------------------------------------- $ gdb ./emacs GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) r -Q Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe -Q Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] [1]+ Stopped gdb ./emacs $ fg gdb ./emacs ---Type <return> to continue, or q <return> to quit--- ------------------------------------------------------------- At this point, after 'return', I have waited more than 20 minutes!!! then I have loaded some files and used 'M-x compile', and in a few secs: ---------------------------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 5509 MARK_INTERVAL_TREE (ptr->intervals); (gdb) bt #0 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 #1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 #2 0x201064f3 in Feval (form=569215053) at /tmp/emacs/src/eval.c:2216 #3 0x20105315 in internal_condition_case_1 (bfun=0x20106450 <Feval>, arg=569215053, handlers=539914913, hfun=0x200a4710 <menu_item_eval_property_1>) at /tmp/emacs/src/eval.c:1525 #4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217) at /tmp/emacs/src/keyboard.c:7270 #5 0x200b0d4e in get_keyelt (object=540146505, autoload=1) at /tmp/emacs/src/keymap.c:829 #6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2, noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655 #7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b648) at /tmp/emacs/src/keyboard.c:7732 #8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0) at /tmp/emacs/src/xdisp.c:9414 #9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098 #10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217) at /tmp/emacs/src/xdisp.c:10935 #11 0x2002d057 in redisplay_preserve_echo_area (from_where=8) at /tmp/emacs/src/xdisp.c:11541 #12 0x200a7aec in detect_input_pending_run_timers (do_display=1) at /tmp/emacs/src/keyboard.c:10061 ---Type <return> to continue, or q <return> to quit--- #13 0x2013a265 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4665 #14 0x20009802 in sit_for (timeout=30, reading=1, do_display=1) at /tmp/emacs/src/dispnew.c:6548 #15 0x200a9590 in read_char (commandflag=1, nmaps=2, maps=0x22c700, prev_event=539858945, used_mouse_menu=0x22c748, end_time=0x0) at /tmp/emacs/src/keyboard.c:2865 #16 0x200ab88d in read_key_sequence (keybuf=0x22c8a0, bufsize=30, prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956 #17 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601 #18 0x2010554f in internal_condition_case (bfun=0x200ad220 <command_loop_1>, handlers=539914913, hfun=0x200a6c80 <cmd_error>) at /tmp/emacs/src/eval.c:1477 #19 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326 #20 0x2010520f in internal_catch (tag=1569454217, func=0x200a0a60 <command_loop_2>, arg=539858945) at /tmp/emacs/src/eval.c:1218 #21 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305 #22 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003 #23 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064 #24 0x2009fd9d in main (argc=2, argv=0x202ce8c0) at /tmp/emacs/src/emacs.c:1794 (gdb) --------------------------------------------------------------------- Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-25 12:56 ` Angelo Graziosi @ 2006-09-25 19:57 ` Eli Zaretskii 2006-09-26 0:06 ` Angelo Graziosi 2006-09-25 20:42 ` Kim F. Storm 1 sibling, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-09-25 19:57 UTC (permalink / raw) Cc: emacs-devel > Date: Mon, 25 Sep 2006 14:56:59 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > > > Good! Although -gdwarf-2 _should_ have produced the same effect. > > > > > $ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello > > > > Do you get the same effect with the following command? > > > > gcc -v -ggdb -g3 hello.c -o hello > > > NO ! It says "Compiled with stabs debugging format." Weird... but anyway, at least you have now a way to produce an Emacs with DWARF 2 debug info. > Program received signal SIGSEGV, Segmentation fault. > 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 > 5509 MARK_INTERVAL_TREE (ptr->intervals); > (gdb) bt > #0 0x200f213c in mark_object (arg=1569454217) at > /tmp/emacs/src/alloc.c:5509 > #1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 It dies in garbage collection. Can you try debugging this using the techniques described in etc/DEBUG (search for "GC")? Failing that, the only idea I have is to try and find the CVS commit that causes the crashes. I think you said that CVS of Sep 4 did build; if that is true, you should be able to find the offending set of changes by successive bisections of the time period since then. The -D switch to CVS will allow you to check-out the tree that was current on a certain date. It's almost certain that the problem was caused by some change in the src directory, so you could consider only the changes in src, at least initially. One other idea is to try "emacs -nw", to see if the crashes are somehow related to the graphics display. Maybe the results will give some ideas, I don't know. Thanks again for working on this. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-25 19:57 ` Eli Zaretskii @ 2006-09-26 0:06 ` Angelo Graziosi 2006-09-26 3:22 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-26 0:06 UTC (permalink / raw) Cc: emacs-devel Eli, Kim, I would be very happy to follow the indications you give me, but, as I wrote, I am not very familiar with GDB so it is very hard for me to follow deeply your suggestions. For the moment what I can say is this: On Mon, 25 Sep 2006, Eli Zaretskii wrote: > > > Program received signal SIGSEGV, Segmentation fault. > > 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 > > 5509 MARK_INTERVAL_TREE (ptr->intervals); > > (gdb) bt > > #0 0x200f213c in mark_object (arg=1569454217) at > > /tmp/emacs/src/alloc.c:5509 > > #1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 > > It dies in garbage collection. Can you try debugging this using the > techniques described in etc/DEBUG (search for "GC")? See above! > > Failing that, the only idea I have is to try and find the CVS commit > that causes the crashes. I think you said that CVS of Sep 4 did > build; if that is true, you should be able to find the offending set > of changes by successive bisections of the time period since then. > The -D switch to CVS will allow you to check-out the tree that was > current on a certain date. It's almost certain that the problem was > caused by some change in the src directory, so you could consider only > the changes in src, at least initially. If I have well understood, I should use: cvs -D20060901 -z3 \ -d:pserver:anonymous@cvs.savannah.gnu.org:/cvsroot/emacs co -P emacs to download the CVS source of Sep 01. If the build works, I should try with Sep 10, for example; if it does not work I should try Sep 05 and so on... > One other idea is to try "emacs -nw", to see if the crashes are > somehow related to the graphics display. Maybe the results will give > some ideas, I don't know. > If I run './emacs -nw' in the directory where the exe was made (/tmp/emacs/.build/src) and from bash-Cygwin.bat, I have $ ./emacs.exe -nw Fatal error (6)Aborted (core dumped) but in the same window+dir: --------------------------------------- $ gdb ./emacs.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... Environment variable "DISPLAY" not defined. TERM = cygwin Breakpoint 1 at 0x2009e476: file /tmp/emacs/src/emacs.c, line 464. Breakpoint 2 at 0x200b7e09: file /tmp/emacs/src/sysdep.c, line 1395. (gdb) r --------------------------------------- it starts and does not seem to have problem. Typing C-x C-c the minibufer says 'C-x C-g undefined' ? I can quit using F-10-File-Exit-Emacs. If I start './emacs &' fro that directory (/tmp/emacs/.build/src) and from an X-window (urxvt) it hangs and I must kill it to reuse the window. The same using gdb. The previous reports regarded emacs started from the installation directory (/usr/local/emacs-22.0.50/bin). Kim F. Storm wrote: > Can you try to debug that using the following gdb commands: > > p arg > xpr > > (and if possible, expand on the value depending on what type of object > it is). See the head of this replay. > Also, can you try to disable the tool-bar and see if the problem still > happens. Now comes something interesting. If you mean 'Options - (Show)/Hide - toolbar' Emacs, './emacs &', from the build dir /tmp/emacs/.build/src, from X (urxvt), after "Options - (Show)/Hide - toolbar" is still running (it is about 1 hour). Thanks for the suggestions, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-26 0:06 ` Angelo Graziosi @ 2006-09-26 3:22 ` Eli Zaretskii 2006-09-26 12:48 ` Angelo Graziosi 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-09-26 3:22 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Tue, 26 Sep 2006 02:06:17 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > I would be very happy to follow the indications you give me, but, as I > wrote, I am not very familiar with GDB so it is very hard for me to follow > deeply your suggestions. Well, Kim just asked you to type 2 GDB commands, one after the other. That shouldn't be hard to follow, and might just give us enough clues to find the culprit. For those two commands to work, you need to start GDB from the Emacs src directory, so that GDB reads the .gdbinit file there. > If I have well understood, I should use: > > > cvs -D20060901 -z3 \ > -d:pserver:anonymous@cvs.savannah.gnu.org:/cvsroot/emacs co -P emacs > > to download the CVS source of Sep 01. If the build works, I should try > with Sep 10, for example; if it does not work I should try Sep 05 and so > on... Yes. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-26 3:22 ` Eli Zaretskii @ 2006-09-26 12:48 ` Angelo Graziosi 2006-09-26 20:10 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-26 12:48 UTC (permalink / raw) Cc: emacs-devel, storm On Tue, 26 Sep 2006, Eli Zaretskii wrote: > Well, Kim just asked you to type 2 GDB commands, one after the other. > That shouldn't be hard to follow, and might just give us enough clues > to find the culprit. Obviously, I will do everything I can. > > For those two commands to work, you need to start GDB from the Emacs > src directory, so that GDB reads the .gdbinit file there. > As I have written in the last replay, I cannot run Emacs from that directory: ------------------------------------------------------------------- cd /tmp/emacs/.build/src $ gdb ./emacs GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x2009e476: file /tmp/emacs/src/emacs.c, line 464. Breakpoint 2 at 0x200b7e89: file /tmp/emacs/src/sysdep.c, line 1395. (gdb) (gdb) r -Q Starting program: /tmp/emacs/.build/src/emacs.exe -Q Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] ------------------------------------------------------------------- At this point it hangs, Emacs does not appear, the urxvt window does not answer (for example, the scroll does not work) : I can only kill GDB (ps - kill...) After killed in that window appears: ------------------------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. [Switching to thread 2148.0xb90] ---Type <return> to continue, or q <return> to quit--- $ <==== PROMPT ========= ------------------------------------------------------------------- If I install Emacs in the prefix directory, I can start Emacs as described yesterday. Regarding the GDB command requested by Kim: > Can you try to debug that using the following gdb commands: > > p arg > xpr I have tried: ------------------------------------------------------------ cd /usr/local/emacs-22.0.50/bin $ gdb ./emacs GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) r Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] [1]+ Stopped gdb ./emacs Angelo@homepc /usr/local/emacs-22.0.50/bin $ fg gdb ./emacs ---Type <return> to continue, or q <return> to quit--- Program received signal SIGSEGV, Segmentation fault. 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 5509 MARK_INTERVAL_TREE (ptr->intervals); (gdb) p arg $1 = 1569454217 (gdb) xpr Undefined command: "xpr". Try "help" ------------------------------------------------------------ Perhaps xpr is a mis-typed command, I have also tried with 'sexpr', 'expr', 'ptr' but with the same result. The thing I want to stress is this: Kim wrote: > Also, can you try to disable the tool-bar and see if the problem still > happens. when I start Emacs as I do normally, i.e. after installed in prefix, $ emacs-cvs & (where emacs-cvs is a link in /usr/local/bin to /usr/local/emacs-22.0.50/bin/emacs.exe) and soon I hide the tool-bar (Options-Show/Hide), then I can work with it for hours without problem, with more than 20 buffers loaded, using M-x compile, C-s (search), M-% (search and replace)....while building e new Emacs-CVS, running other C/C++/Fortran programs etc. Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-26 12:48 ` Angelo Graziosi @ 2006-09-26 20:10 ` Eli Zaretskii 2006-09-26 22:18 ` Angelo Graziosi ` (2 more replies) 0 siblings, 3 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-26 20:10 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Tue, 26 Sep 2006 14:48:40 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > > > For those two commands to work, you need to start GDB from the Emacs > > src directory, so that GDB reads the .gdbinit file there. > > > > As I have written in the last replay, I cannot run Emacs from that > directory: Sorry, I forgot. It is strange that changing a directory has this effect, but here are a few possibilities to work around the problem. All of the following possibilities assume you start from the `src' directory: 1) gdb ./emacs.exe 2) gdb /usr/local/emacs-22.0.50/bin/emacs.exe 3) cd /usr/local/emacs-22.0.50/bin gdb ./emacs.exe (gdb) source /tmp/emacs/.build/src/.gdbinit If none of the above helps get rid of the hang, try to edit the file src/.gdbinit so that it is left only with definitions of commands (each definition is a block that starts with "define" and ends with "end") and their documentation (blocks that start with "document"), and remove everything else. > (gdb) xpr > Undefined command: "xpr". Try "help" > ------------------------------------------------------------ > > Perhaps xpr is a mis-typed command No, it's a command defined in src/.gdbinit. If you don't start GDB from the src directory and don't "source" that file from within GDB, this command will be unknown to GDB. > > Also, can you try to disable the tool-bar and see if the problem still > > happens. > > when I start Emacs as I do normally, i.e. after installed in prefix, > > $ emacs-cvs & > > (where emacs-cvs is a link in /usr/local/bin to > /usr/local/emacs-22.0.50/bin/emacs.exe) > > and soon I hide the tool-bar (Options-Show/Hide), then I can work with it > for hours without problem, with more than 20 buffers loaded, using M-x > compile, C-s (search), M-% (search and replace)....while building e new > Emacs-CVS, running other C/C++/Fortran programs etc. Interesting. So without the tool bar it never crashes, no matter how long you leave it? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-26 20:10 ` Eli Zaretskii @ 2006-09-26 22:18 ` Angelo Graziosi 2006-09-27 3:35 ` Eli Zaretskii 2006-09-27 16:52 ` Angelo Graziosi 2006-09-27 18:14 ` Angelo Graziosi 2 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-26 22:18 UTC (permalink / raw) Cc: emacs-devel, storm On Tue, 26 Sep 2006, Eli Zaretskii wrote: > > It is strange that changing a directory has this effect, but here are > a few possibilities to work around the problem. All of the following > possibilities assume you start from the `src' directory: > > 1) gdb ./emacs.exe > > 2) gdb /usr/local/emacs-22.0.50/bin/emacs.exe > > 3) cd /usr/local/emacs-22.0.50/bin > gdb ./emacs.exe > (gdb) source /tmp/emacs/.build/src/.gdbinit > > If none of the above helps get rid of the hang, try to edit the file > src/.gdbinit so that it is left only with definitions of commands > (each definition is a block that starts with "define" and ends with > "end") and their documentation (blocks that start with "document"), > and remove everything else. I will try your suggestions. In any case there are other strange things. This morning (20060926 about 10:00 am) I have downloaded a new CVS source of Emacs and have made e new build using the debug options we discussed (CFLAGS='-ggdb -gdwarf-2 -g3 -O2'). Then I have installed (prefix=/usr/local/emacs-22.0.50) it. Obviously it does not work in the build dir but I can start it as usually with an adeguate link $ emacs-cvs & (/usr/local/bin/emacs-cvs -> /usr/local/emacs-22.0.50/bin/emacs.exe) I have worked with it without problem, also with tool-bar On! I haven't observed any crash. Seeing this i decided to make a new build without debug options (CFLAGS='-O2')...installed etc... : $ emacs-cvs & works only if 'cd /usr/local'. If it is given in any other directory Emacs core dumps! > > Interesting. So without the tool bar it never crashes, no matter how > long you leave it? > All the time (hours) I worked with it I haven't seen any crash. Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-26 22:18 ` Angelo Graziosi @ 2006-09-27 3:35 ` Eli Zaretskii 0 siblings, 0 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-27 3:35 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Wed, 27 Sep 2006 00:18:29 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > In any case there are other strange things. > > This morning (20060926 about 10:00 am) I have downloaded a new CVS source > of Emacs and have made e new build using the debug options we discussed > (CFLAGS='-ggdb -gdwarf-2 -g3 -O2'). Then I have installed > (prefix=/usr/local/emacs-22.0.50) it. > > Obviously it does not work in the build dir but I can start it as usually > with an adeguate link > > $ emacs-cvs & > > (/usr/local/bin/emacs-cvs -> /usr/local/emacs-22.0.50/bin/emacs.exe) > > I have worked with it without problem, also with tool-bar On! I haven't > observed any crash. > > Seeing this i decided to make a new build without debug options > (CFLAGS='-O2')...installed etc... : > > $ emacs-cvs & > > works only if 'cd /usr/local'. If it is given in any other directory Emacs > core dumps! It sounds like memory corruption of some kind. They frequently exhibit such strange patterns. Until we resolve this, I'd suggest not to rebuild the latest version, so that the bug doesn't move too much. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-26 20:10 ` Eli Zaretskii 2006-09-26 22:18 ` Angelo Graziosi @ 2006-09-27 16:52 ` Angelo Graziosi 2006-09-27 18:22 ` Eli Zaretskii 2006-09-27 18:14 ` Angelo Graziosi 2 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-27 16:52 UTC (permalink / raw) Cc: emacs-devel, storm On Tue, 26 Sep 2006, Eli Zaretskii wrote: > > It is strange that changing a directory has this effect, but here are > a few possibilities to work around the problem. All of the following > possibilities assume you start from the `src' directory: > > 1) gdb ./emacs.exe > > 2) gdb /usr/local/emacs-22.0.50/bin/emacs.exe > > 3) cd /usr/local/emacs-22.0.50/bin > gdb ./emacs.exe > (gdb) source /tmp/emacs/.build/src/.gdbinit It is .gdbinit that causes the problem. I have tried 1)...3) but only if I rename .gdbinit (for example save.gdbinit) I can run Emacs from GDB whatever is the directory. > > If none of the above helps get rid of the hang, try to edit the file > src/.gdbinit so that it is left only with definitions of commands > (each definition is a block that starts with "define" and ends with > "end") and their documentation (blocks that start with "document"), > and remove everything else. I will try. Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-27 16:52 ` Angelo Graziosi @ 2006-09-27 18:22 ` Eli Zaretskii 2006-09-28 10:18 ` Angelo Graziosi 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-09-27 18:22 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Wed, 27 Sep 2006 18:52:58 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > It is .gdbinit that causes the problem. I have tried 1)...3) but only if I > rename .gdbinit (for example save.gdbinit) I can run Emacs from GDB > whatever is the directory. > > > If none of the above helps get rid of the hang, try to edit the file > > src/.gdbinit so that it is left only with definitions of commands > > (each definition is a block that starts with "define" and ends with > > "end") and their documentation (blocks that start with "document"), > > and remove everything else. > > I will try. And if that doesn't help either, please try to find what part in .gdbinit causes the problem (e.g., by deleting parts of it and trying to run Emacs under GDB). ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-27 18:22 ` Eli Zaretskii @ 2006-09-28 10:18 ` Angelo Graziosi 2006-09-30 9:30 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-28 10:18 UTC (permalink / raw) Cc: emacs-devel, storm On Wed, 27 Sep 2006, Eli Zaretskii wrote: > > And if that doesn't help either, please try to find what part in > .gdbinit causes the problem (e.g., by deleting parts of it and trying > to run Emacs under GDB). > I have tried with the following result. The problem is localized between lines 1072 # People get bothered when... ..... ..... 1110 end I have subdivided them in three blocks: A == (1072 - 1094) B == (1095 - 1095) C == (1096 - 1110) The results are summarized by the following table: A B C | Result 0 0 0 | H 0 0 1 | H 0 1 0 | H 0 1 1 | H 1 0 0 | H 1 0 1 | H 1 1 0 | E 1 1 1 | W Where '1' means that the lines of that block are short-circuited (with a '#'), ' '0' the line remains as in the original .gdbinit 'H' the result hangs, i.e. ------------------------------------------------------- ... Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] IT HANGS, I must kill it Program received signal SIGSEGV, Segmentation fault. [Switching to thread 4068.0xc50] ---Type <return> to continue, or q <return> to quit---Killed ------------------------------------------------------- 'E' .gdbinit has errors and it seems ignored, i.e. ------------------------------------------------------ .... This GDB was configured as "i686-pc-cygwin"... DISPLAY = :0.0 TERM = xterm /tmp/emacs/.build/src/.gdbinit:1: Error in sourced command file: /tmp/emacs/src/.gdbinit:1096: Error in sourced command file: No breakpoint number 0. ------------------------------------------------------ 'W' starting Emacs with GDB works, ---------------------------------------------------------------- cd /tmp/emacs/.build/src $ gdb ./emacs.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... DISPLAY = :0.0 TERM = xterm (gdb) r Starting program: /tmp/emacs/.build/src/emacs.exe -geometry 80x40+0+0 Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] [1]+ Stopped gdb ./emacs.exe $ fg gdb ./emacs.exe ---Type <return> to continue, or q <return> to quit--- AFTER A FEW MINUTES Program received signal SIGSEGV, Segmentation fault. 0x200f217c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 5509 MARK_INTERVAL_TREE (ptr->intervals); (gdb) bt #0 0x200f217c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 #1 0x200f2a4f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 #2 0x20106533 in Feval (form=568921741) at /tmp/emacs/src/eval.c:2216 #3 0x20105355 in internal_condition_case_1 (bfun=0x20106490 <Feval>, arg=568921741, handlers=539914913, hfun=0x200a4710 <menu_item_eval_property_1>) at /tmp/emacs/src/eval.c:1525 #4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217) at /tmp/emacs/src/keyboard.c:7270 #5 0x200b0d4e in get_keyelt (object=540146505, autoload=1) at /tmp/emacs/src/keymap.c:829 #6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2, noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655 #7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b688) at /tmp/emacs/src/keyboard.c:7732 #8 0x2001d51f in update_tool_bar (f=0x2192d000, save_match_data=0) at /tmp/emacs/src/xdisp.c:9414 #9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098 #10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217) at /tmp/emacs/src/xdisp.c:10935 #11 0x2002d08a in redisplay_preserve_echo_area (from_where=8) at /tmp/emacs/src/xdisp.c:11545 #12 0x200a7aec in detect_input_pending_run_timers (do_display=1) at /tmp/emacs/src/keyboard.c:10061 ---Type <return> to continue, or q <return> to quit--- #13 0x2013a2a5 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4665 #14 0x200a8e40 in read_char (commandflag=1, nmaps=2, maps=0x22c700, prev_event=539858945, used_mouse_menu=0x22c748, end_time=0x0) at /tmp/emacs/src/keyboard.c:3988 #15 0x200ab88d in read_key_sequence (keybuf=0x22c8a0, bufsize=30, prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956 #16 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601 #17 0x2010558f in internal_condition_case (bfun=0x200ad220 <command_loop_1>, handlers=539914913, hfun=0x200a6c80 <cmd_error>) at /tmp/emacs/src/eval.c:1477 #18 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326 #19 0x2010524f in internal_catch (tag=1569454217, func=0x200a0a60 <command_loop_2>, arg=539858945) at /tmp/emacs/src/eval.c:1218 #20 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305 #21 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003 #22 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064 #23 0x2009fd9d in main (argc=3, argv=0x202ce900) at /tmp/emacs/src/emacs.c:1794 (gdb) p arg $1 = 1569454217 (gdb) xpr Lisp_Symbol $2 = (struct Lisp_Symbol *) 0x7d8bf888 Cannot access memory at address 0x7d8bf88c (gdb) ---------------------------------------------------------------- I want to flag that on Cygwin mailing list there are peoples that have similar problems with GDB (http://cygwin.com/ml/cygwin/2006-09/msg00534.html). Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-28 10:18 ` Angelo Graziosi @ 2006-09-30 9:30 ` Eli Zaretskii 2006-09-30 10:16 ` Angelo Graziosi 2006-09-30 23:34 ` Building " Kim F. Storm 0 siblings, 2 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-30 9:30 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Thu, 28 Sep 2006 12:18:00 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > The problem is localized between lines > > > 1072 # People get bothered when... > ..... ..... > > 1110 end This is somewhat tangential to the real problem at hand, but as long as we are talking about this: what happens if you remove all that block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and then manually type the commands in the offending block, one after the other? I'm particularly interested to know whether you see any error messages from GDB, and if so, which line causes these messages. > (gdb) xpr > Lisp_Symbol > $2 = (struct Lisp_Symbol *) 0x7d8bf888 > Cannot access memory at address 0x7d8bf88c > (gdb) Kim, any clever ideas, before we ask Angelo to look in last_marked[] array etc.? > I want to flag that on Cygwin mailing list there are peoples that have > similar problems with GDB > (http://cygwin.com/ml/cygwin/2006-09/msg00534.html). Yes, I've seen that thread, but I don't see any useful (i.e., that explain what's going on and why) responses to the problem it reported. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-30 9:30 ` Eli Zaretskii @ 2006-09-30 10:16 ` Angelo Graziosi 2006-09-30 14:47 ` Eli Zaretskii 2006-09-30 23:34 ` Building " Kim F. Storm 1 sibling, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-30 10:16 UTC (permalink / raw) Cc: emacs-devel, storm On Sat, 30 Sep 2006, Eli Zaretskii wrote: > > Date: Thu, 28 Sep 2006 12:18:00 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > cc: storm@cua.dk, emacs-devel@gnu.org > > > > The problem is localized between lines > > > > > > 1072 # People get bothered when... > > ..... ..... > > > > 1110 end > > This is somewhat tangential to the real problem at hand, but as long > as we are talking about this: what happens if you remove all that > block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and > then manually type the commands in the offending block, one after the ^^^^^^^^^^^^^^^^^^^^^^^^^^ ???? > other? I'm particularly interested to know whether you see any error > messages from GDB, and if so, which line causes these messages. This is not clear: - I remove the blocks A,B,C from .gdbinit - then start gdb ./emacs... - then add a line at time of the removed blocks: Add to .gdbinit or at GDB prompt ? As I wrote, removing the block C causes GDB sayd .gdbinit has errors. Cheers Angelo. > > > (gdb) xpr > > Lisp_Symbol > > $2 = (struct Lisp_Symbol *) 0x7d8bf888 > > Cannot access memory at address 0x7d8bf88c > > (gdb) > > Kim, any clever ideas, before we ask Angelo to look in last_marked[] > array etc.? > > > I want to flag that on Cygwin mailing list there are peoples that have > > similar problems with GDB > > (http://cygwin.com/ml/cygwin/2006-09/msg00534.html). > > Yes, I've seen that thread, but I don't see any useful (i.e., that > explain what's going on and why) responses to the problem it reported. > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-30 10:16 ` Angelo Graziosi @ 2006-09-30 14:47 ` Eli Zaretskii 2006-09-30 16:49 ` Angelo Graziosi 2006-09-30 17:00 ` Problems with 'make install' after the build of " Angelo Graziosi 0 siblings, 2 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-09-30 14:47 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Sat, 30 Sep 2006 12:16:17 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > > > This is somewhat tangential to the real problem at hand, but as long > > as we are talking about this: what happens if you remove all that > > block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and > > then manually type the commands in the offending block, one after the > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > ???? > > > other? I'm particularly interested to know whether you see any error > > messages from GDB, and if so, which line causes these messages. > > > This is not clear: > > - I remove the blocks A,B,C from .gdbinit > - then start gdb ./emacs... > - then add a line at time of the removed blocks: Add to .gdbinit or at GDB > prompt ? Type the commands at the GDB prompt one by one, in the order they appear in the original .gdbinit. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-30 14:47 ` Eli Zaretskii @ 2006-09-30 16:49 ` Angelo Graziosi 2006-10-01 16:54 ` Eli Zaretskii 2006-09-30 17:00 ` Problems with 'make install' after the build of " Angelo Graziosi 1 sibling, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-30 16:49 UTC (permalink / raw) Cc: emacs-devel, storm On Sat, 30 Sep 2006, Eli Zaretskii wrote: > > Date: Sat, 30 Sep 2006 12:16:17 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > cc: storm@cua.dk, emacs-devel@gnu.org > > > > > > This is somewhat tangential to the real problem at hand, but as long > > > as we are talking about this: what happens if you remove all that > > > block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and > > > then manually type the commands in the offending block, one after the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ???? > > > > > other? I'm particularly interested to know whether you see any error > > > messages from GDB, and if so, which line causes these messages. > > > > > > This is not clear: > > > > - I remove the blocks A,B,C from .gdbinit > > - then start gdb ./emacs... > > - then add a line at time of the removed blocks: Add to .gdbinit or at GDB > > prompt ? > > Type the commands at the GDB prompt one by one, in the order they > appear in the original .gdbinit. > As I thinked, --------------------------------------------------------------------- cd /tmp/emacs/.build/src $ gdb ./emacs.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... DISPLAY = :0.0 TERM = xterm (gdb) xgetptr Vsystem_type (gdb) if ($ptr != 0) >set $tem = (struct Lisp_Symbol *) $ptr >xgetptr $tem->xname >set $tem = (struct Lisp_String *) $ptr >set $tem = (char *) $tem->data >if $tem[0] == 'w' && $tem[1] == 'i' && $tem[2] == 'n' && $tem[3] == 'd' >break w32_abort >else > break abort >end >end Breakpoint 1 at 0x2009e476: file /tmp/emacs/src/emacs.c, line 464. (gdb) tbreak init_sys_modes Breakpoint 2 at 0x200b7e89: file /tmp/emacs/src/sysdep.c, line 1395. (gdb) commands Type commands for when breakpoint 2 is hit, one per line. End with a line saying just "end". >silent >xgetptr Vwindow_system >set $tem = (struct Lisp_Symbol *) $ptr >xgetptr $tem->xname >set $tem = (struct Lisp_String *) $ptr >set $tem = (char *) $tem->data >if $tem[0] == 'x' && $tem[1] == '\0' >break x_error_quitter >end >continue >end (gdb) --------------------------------------------------------------------- Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-30 16:49 ` Angelo Graziosi @ 2006-10-01 16:54 ` Eli Zaretskii 2006-10-01 21:29 ` Angelo Graziosi 2006-10-25 22:32 ` Angelo Graziosi 0 siblings, 2 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-10-01 16:54 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Sat, 30 Sep 2006 18:49:05 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > > > Type the commands at the GDB prompt one by one, in the order they > > appear in the original .gdbinit. > > > > As I thinked, Can you explain what you thought? Anyway, this is not the main problem, so I'll drop this side issue for now. Thanks. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-01 16:54 ` Eli Zaretskii @ 2006-10-01 21:29 ` Angelo Graziosi 2006-10-25 22:32 ` Angelo Graziosi 1 sibling, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-10-01 21:29 UTC (permalink / raw) Cc: Angelo Graziosi, emacs-devel, storm On Sun, 1 Oct 2006, Eli Zaretskii wrote: > > Date: Sat, 30 Sep 2006 18:49:05 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > cc: storm@cua.dk, emacs-devel@gnu.org > > > > > > Type the commands at the GDB prompt one by one, in the order they > > > appear in the original .gdbinit. > > > > > > > As I thinked, > > Can you explain what you thought? I thinked it was the most likely but I was not sure to have right interpreted your words. Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-01 16:54 ` Eli Zaretskii 2006-10-01 21:29 ` Angelo Graziosi @ 2006-10-25 22:32 ` Angelo Graziosi 2006-10-26 7:48 ` Eli Zaretskii 2006-10-26 8:53 ` Richard Stallman 1 sibling, 2 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-10-25 22:32 UTC (permalink / raw) Cc: emacs-devel, storm There is some news regarding the behaviour of GDB and I flag this for the sake of completeness. I have repost the GDB problem to Cygwin list http://cygwin.com/ml/cygwin/2006-10/msg00843.html and this time I have got a little answer http://cygwin.com/ml/cygwin/2006-10/msg00848.html This help me to some conclusions http://cygwin.com/ml/cygwin/2006-10/msg00850.html http://cygwin.com/ml/cygwin/2006-10/msg00851.html i.e. GCC-4.0.3, 4.3.0 (and also 3.4.4-1) works correctly with GDB but not GCC-3.4.4-2 (exp. package in Cygwin, it applies the '24196' patch) which I used to build hello.c and Emacs-cvs. For some strange reason, using '-g' with GCC-3.4.4-2 does not insert the right debug symbols in the executable. Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-25 22:32 ` Angelo Graziosi @ 2006-10-26 7:48 ` Eli Zaretskii 2006-10-26 8:21 ` Angelo Graziosi 2006-10-26 8:53 ` Richard Stallman 1 sibling, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-26 7:48 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Thu, 26 Oct 2006 00:32:47 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > i.e. GCC-4.0.3, 4.3.0 (and also 3.4.4-1) works correctly with GDB but not > GCC-3.4.4-2 (exp. package in Cygwin, it applies the '24196' patch) which I > used to build hello.c and Emacs-cvs. > > For some strange reason, using '-g' with GCC-3.4.4-2 does not insert the > right debug symbols in the executable. Thanks for the update. If you bootstrap Emacs with a version of GCC that does produce the correct debug symbols, does the original problem (Emacs crashing or hanging) disappear? If it does not disappear, can you at least run Emacs under GDB (perhaps upgrade your GDB as well to the latest Cygwin port) and see where it crashes/hangs? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 7:48 ` Eli Zaretskii @ 2006-10-26 8:21 ` Angelo Graziosi 2006-10-26 8:57 ` Jason Rumney ` (2 more replies) 0 siblings, 3 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-10-26 8:21 UTC (permalink / raw) Cc: emacs-devel, storm On Thu, 26 Oct 2006, Eli Zaretskii wrote: > If you bootstrap Emacs with a version of GCC that does produce the > correct debug symbols, does the original problem (Emacs crashing or > hanging) disappear? I am bootstrapping with GCC-4.0.3 it take about 3 hours on my system. ========= But what I have just done since yesterday is this. I had a build tree (CVS 20061025 15:00) on Linux, so I have run make distclean then I have packed the tree and tranfered it on Window-Cygwin. Here I have updated CVS and added a pointer to GCC-4.0.3 bin dir export PATH=/usr/local/g95/bin:$PATH gcc -v in the build script for Emacs-CVS. This script run ... ../configure --prefix=... make cd lisp make autoloads EMACS=../src/emacs make recompile EMACS=../src/emacs cd .. make make install This Emacs-CVS build seems to run without any crashing! Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 8:21 ` Angelo Graziosi @ 2006-10-26 8:57 ` Jason Rumney 2006-10-26 15:46 ` Angelo Graziosi 2006-10-26 10:12 ` Building Emacs-cvs on Cygwin Richard Stallman 2006-10-26 15:12 ` Eli Zaretskii 2 siblings, 1 reply; 75+ messages in thread From: Jason Rumney @ 2006-10-26 8:57 UTC (permalink / raw) Cc: Eli Zaretskii, storm, emacs-devel Angelo Graziosi wrote: > This Emacs-CVS build seems to run without any crashing! > That is a good sign, but your original symptoms were very similar to a case we had when compiling 21.3 and 21.4 with recent MingW ports of gcc. In that case the cause was that .elc files had been written in DOS text mode (converting \n to \r\n and terminating the file when a ^Z character was encountered). If the problem is the same, it will only show up when you bootstrap with that build of Emacs, since elc files compiled on another platform will not have the same problem. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 8:57 ` Jason Rumney @ 2006-10-26 15:46 ` Angelo Graziosi 2006-10-27 8:41 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-10-26 15:46 UTC (permalink / raw) Cc: Eli Zaretskii, storm, emacs-devel On Thu, 26 Oct 2006, Jason Rumney wrote: > Angelo Graziosi wrote: > > This Emacs-CVS build seems to run without any crashing! > > > > That is a good sign, but your original symptoms were very similar to a > case we had when compiling 21.3 and 21.4 with recent MingW ports of gcc. > In that case the cause was that .elc files had been written in DOS text > mode (converting \n to \r\n and terminating the file when a ^Z character > was encountered). If the problem is the same, it will only show up when > you bootstrap with that build of Emacs, since elc files compiled on > another platform will not have the same problem. I have bootstrapped Emacs-CVS on Cygwin with GCC-4.0.3. Then I started Emacs at 13:20 and it is still running (17:19) without crashing. It would be desirable that others build Emacs-CVS on Cygwin with a GCC-4 branch to confirm the above. It seems that GCC-3.4.4-2 (exp) on Cygwin is broken with the '-g' option. Regarding GCC-4.0.3, it does not belongs to Cygwin yet, I built it myself (only the core, C language) because it needs to build G95. Regarding the observations of Jason, there are a few *.elc file that some editor (Crimson) reports as in DOS format (Emacs shows -=:--). I have examined a few of these *.elc files and the only differences between those produced on GNU/Linux (thanks, RMS, to have remembered me this) and those on Windows-Cygwin are the compiling date and the name of machines, desktop-angelo on GNU/Linux, homepc on Win-Cygwin. At first sight it seems that the bootstrapped and the hybrid builds are very similar. Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 15:46 ` Angelo Graziosi @ 2006-10-27 8:41 ` Eli Zaretskii 2006-10-27 16:34 ` Angelo Graziosi 2006-10-28 0:16 ` Angelo Graziosi 0 siblings, 2 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-10-27 8:41 UTC (permalink / raw) Cc: emacs-devel, storm, jasonr > Date: Thu, 26 Oct 2006 17:46:01 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, storm@cua.dk > > I have bootstrapped Emacs-CVS on Cygwin with GCC-4.0.3. > > Then I started Emacs at 13:20 and it is still running (17:19) without > crashing. Thanks for the testing. > It would be desirable that others build Emacs-CVS on Cygwin with a GCC-4 > branch to confirm the above. It seems that GCC-3.4.4-2 (exp) on Cygwin is > broken with the '-g' option. > > Regarding GCC-4.0.3, it does not belongs to Cygwin yet, I built it myself > (only the core, C language) because it needs to build G95. But you also said in an earlier message that GCC 3.4.4-1 didn't have the -g bug. Could you please try to build with that version? If version 3.4.4-2 is the only one to avoid, I'd like to say that explicitly in etc/PROBLEMS, because building GCC is something most Cygwin users will probably not wish to do. > Regarding the observations of Jason, there are a few *.elc file that some > editor (Crimson) reports as in DOS format (Emacs shows -=:--). > > I have examined a few of these *.elc files and the only differences > between those produced on GNU/Linux (thanks, RMS, to have remembered me > this) and those on Windows-Cygwin are the compiling date and the name of > machines, desktop-angelo on GNU/Linux, homepc on Win-Cygwin. Sounds like these are false hits, and that the problem mentioned by Jason doesn't exist. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-27 8:41 ` Eli Zaretskii @ 2006-10-27 16:34 ` Angelo Graziosi 2006-10-28 0:16 ` Angelo Graziosi 1 sibling, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-10-27 16:34 UTC (permalink / raw) Cc: Angelo Graziosi, emacs-devel, storm, jasonr On Fri, 27 Oct 2006, Eli Zaretskii wrote: > > But you also said in an earlier message that GCC 3.4.4-1 didn't have > the -g bug. Could you please try to build with that version? If > version 3.4.4-2 is the only one to avoid, I'd like to say that > explicitly in etc/PROBLEMS, because building GCC is something most > Cygwin users will probably not wish to do. I should try only with GCC-3.4.4-1 because I have just tried bootstrapping the same Emacs-CVS with GCC-4.3.0 20061022 (experimental) and have re-tried with GCC-3.4.4-2: Only 3.4.4-2 segment fault! Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-27 8:41 ` Eli Zaretskii 2006-10-27 16:34 ` Angelo Graziosi @ 2006-10-28 0:16 ` Angelo Graziosi 2006-10-28 12:16 ` Eli Zaretskii 1 sibling, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-10-28 0:16 UTC (permalink / raw) Cc: emacs-devel, storm, jasonr On Fri, 27 Oct 2006, Eli Zaretskii wrote: > But you also said in an earlier message that GCC 3.4.4-1 didn't have > the -g bug. Could you please try to build with that version? If > version 3.4.4-2 is the only one to avoid, I'd like to say that > explicitly in etc/PROBLEMS, because building GCC is something most > Cygwin users will probably not wish to do. I have boostrapped also with GCC-3.4.4-1 (curr. in Cygwin) and Emacs segment faults. I have observed that configuring with GCC-4.0.3 or 4.3.0 20061022 (experimental), 'configure' reports What compiler should emacs be built with? gcc -g -O2 -Wno-pointer-sign while with GCC-3.4.4 What compiler should emacs be built with? gcc -g -O2 but I do not think that this is the difference. Beside this, the build with GCC-4.3.0 20061022 (experimental) has the problem that hitting 'M-x' gives (in the minibuffer) M-x undefined So, for the moment, only the build with GCC-4.0.3 seems very fine on Cygwin. At this point it would remain to boostrap Emacs with GCC-4.1.1 (current release from GCC site) or 4.2 (next release on GCC) but I haven't these versions built of gcc. Cheers Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-28 0:16 ` Angelo Graziosi @ 2006-10-28 12:16 ` Eli Zaretskii 2006-10-29 11:13 ` Building Emacs-cvs on Cygwin (GCC summary) Angelo Graziosi 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-28 12:16 UTC (permalink / raw) Cc: emacs-devel, storm, jasonr > Date: Sat, 28 Oct 2006 02:16:04 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: jasonr@gnu.org, emacs-devel@gnu.org, storm@cua.dk > > I have observed that configuring with GCC-4.0.3 or 4.3.0 20061022 > (experimental), 'configure' reports > > > What compiler should emacs be built with? gcc -g -O2 -Wno-pointer-sign > > while with GCC-3.4.4 > > What compiler should emacs be built with? gcc -g -O2 > > > but I do not think that this is the difference. It only makes a difference if you see any warnings during compilation that complain about passing pointers to signed/unsigned data types. Thanks for testing this. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin (GCC summary) 2006-10-28 12:16 ` Eli Zaretskii @ 2006-10-29 11:13 ` Angelo Graziosi 0 siblings, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-10-29 11:13 UTC (permalink / raw) Cc: emacs-devel, storm, jasonr I have bootstrapped Emacs-cvs (22.0.90) with different GCC version on Cygwin and this is the summary of results: GCC-3.4.4-(1/2) Segment fault GCC-4.0.3 OK GCC-4.1.1 OK GCC-4.2-20061024(prerelease) M-x undefined GCC-4.3-20061022(experim.) M-x undefined In conclusion on Cygwin only the build with GCC-4.0.3 and 4.1.1 seem to work fine. Are there people that can confirm these results? It would be very apreciated. Thanks, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 8:21 ` Angelo Graziosi 2006-10-26 8:57 ` Jason Rumney @ 2006-10-26 10:12 ` Richard Stallman 2006-10-26 10:24 ` David Kastrup 2006-10-26 15:12 ` Eli Zaretskii 2 siblings, 1 reply; 75+ messages in thread From: Richard Stallman @ 2006-10-26 10:12 UTC (permalink / raw) Cc: eliz, storm, emacs-devel I had a build tree (CVS 20061025 15:00) on Linux, so I have run I think you mean "on GNU/Linux", because that is a complete system, comparable to Microsoft Windows. This Emacs-CVS build seems to run without any crashing! I guess that means the bug has been fixed by newer GCC versions. That is good. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 10:12 ` Building Emacs-cvs on Cygwin Richard Stallman @ 2006-10-26 10:24 ` David Kastrup 2006-10-26 15:06 ` Eli Zaretskii 2006-10-26 20:40 ` Richard Stallman 0 siblings, 2 replies; 75+ messages in thread From: David Kastrup @ 2006-10-26 10:24 UTC (permalink / raw) Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > I had a build tree (CVS 20061025 15:00) on Linux, so I have run > > I think you mean "on GNU/Linux", because that is a complete system, > comparable to Microsoft Windows. Microsoft Windows is not a complete system, as it is missing most end user applications, and is also lacking the toolbox inventory of small utilities that are a necessary ingredient of POSIX systems. One has to add quite a bit of GNU stuff to MS Windows before it becomes comparably useful. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 10:24 ` David Kastrup @ 2006-10-26 15:06 ` Eli Zaretskii 2006-10-26 15:12 ` David Kastrup 2006-10-26 20:40 ` Richard Stallman 1 sibling, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-26 15:06 UTC (permalink / raw) Cc: emacs-devel > From: David Kastrup <dak@gnu.org> > Date: Thu, 26 Oct 2006 12:24:40 +0200 > Cc: emacs-devel@gnu.org > > Microsoft Windows is not a complete system, as it is missing most end > user applications, and is also lacking the toolbox inventory of small > utilities that are a necessary ingredient of POSIX systems. What exactly is missing that makes you say this? A bare-bones Linux kernel lacks even a shell and basic commands like ls and cp, which are all GNU programs, but MS-Windows does come with the equivalents of these commands out of the box. > One has to add quite a bit of GNU stuff to MS Windows before it > becomes comparably useful. ``Useful'' is in the eyes of the beholder. ``Usable'' is a more relevant issue: stripped of all GNU programs, a Linux-based system is simply unusable, IMO. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 15:06 ` Eli Zaretskii @ 2006-10-26 15:12 ` David Kastrup 2006-10-27 8:17 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: David Kastrup @ 2006-10-26 15:12 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: David Kastrup <dak@gnu.org> >> Date: Thu, 26 Oct 2006 12:24:40 +0200 >> Cc: emacs-devel@gnu.org >> >> Microsoft Windows is not a complete system, as it is missing most >> end user applications, and is also lacking the toolbox inventory of >> small utilities that are a necessary ingredient of POSIX systems. > > What exactly is missing that makes you say this? > > A bare-bones Linux kernel Which neither Richard nor I was talking about. Richard was clearly talking about a GNU/Linux system, and so was I. And Richard called a GNU/Linux system comparable to MS Windows, and I said that MS Windows did not compare well at all in that regard. So I don't know what straw men you are trying to beat here. > lacks even a shell and basic commands like ls and cp, which are all > GNU programs, but MS-Windows does come with the equivalents of these > commands out of the box. But the MS Windows versions of even those primitive commands are much less useful, particular in scripts, than the GNU equivalents. >> One has to add quite a bit of GNU stuff to MS Windows before it >> becomes comparably useful. > > ``Useful'' is in the eyes of the beholder. ``Usable'' is a more > relevant issue: stripped of all GNU programs, a Linux-based system > is simply unusable, IMO. So what? Richard was not talking about just a kernel, I was not talking about just a kernel. What is your fixation with a bare Linux kernel? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 15:12 ` David Kastrup @ 2006-10-27 8:17 ` Eli Zaretskii 2006-10-27 9:04 ` David Kastrup 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-27 8:17 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Thu, 26 Oct 2006 17:12:03 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > What exactly is missing that makes you say this? You didn't answer that. > > A bare-bones Linux kernel > > Which neither Richard nor I was talking about. Neither was I, sorry for the confusing wording. I later used a more accurate (but much longer) term "GNU/Linux with all the GNU commands removed". > But the MS Windows versions of even those primitive commands are much > less useful, particular in scripts, than the GNU equivalents. When did you last looked at those commands? They are much more powerful since at least 6 years ago. If you have examples of the functionality you think is missing, let's hear them. > > ``Useful'' is in the eyes of the beholder. ``Usable'' is a more > > relevant issue: stripped of all GNU programs, a Linux-based system > > is simply unusable, IMO. > > So what? Richard was not talking about just a kernel, I was not > talking about just a kernel. > > What is your fixation with a bare Linux kernel? There is none. I didn't even use that term in the part to which you were responding here. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-27 8:17 ` Eli Zaretskii @ 2006-10-27 9:04 ` David Kastrup 2006-10-28 10:49 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: David Kastrup @ 2006-10-27 9:04 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Cc: emacs-devel@gnu.org >> From: David Kastrup <dak@gnu.org> >> Date: Thu, 26 Oct 2006 17:12:03 +0200 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > What exactly is missing that makes you say this? > > You didn't answer that. > >> > A bare-bones Linux kernel >> >> Which neither Richard nor I was talking about. > > Neither was I, sorry for the confusing wording. I later used a more > accurate (but much longer) term "GNU/Linux with all the GNU commands > removed". But nobody was talking about that except you. So the problem does not appear to be with your wording. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-27 9:04 ` David Kastrup @ 2006-10-28 10:49 ` Eli Zaretskii 2006-10-29 18:45 ` Richard Stallman 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-28 10:49 UTC (permalink / raw) Cc: emacs-devel > From: David Kastrup <dak@gnu.org> > Date: Fri, 27 Oct 2006 11:04:39 +0200 > Cc: emacs-devel@gnu.org > > > >> > A bare-bones Linux kernel > >> > >> Which neither Richard nor I was talking about. > > > > Neither was I, sorry for the confusing wording. I later used a more > > accurate (but much longer) term "GNU/Linux with all the GNU commands > > removed". > > But nobody was talking about that except you. So the problem does not > appear to be with your wording. I no longer know what you were talking about. What you seem to say is of no practical importance, and here's why: GNU/Linux is called that way because without GNU programs that system is unusable, even though more than half of what comes with the system are not GNU programs. Richard is asking people to use the bare "Linux" term only in conjunction with the Linux kernel, and I have no problem with that; but that doesn't mean that the GNU/Linux system is simply a combination of GNU programs and the Linux kernel. It is a logical fallacy to think so. In particular, it is clear to everyone that a kernel alone, without any programs that use that kernel or at least have the ability to load and run a program on that kernel, is useless. So, IMO, in practical terms, it doesn't make sense to talk about the Linux kernel as opposed to MS-Windows without GNU software. The correct comparison is of a GNU/Linux system without any GNU software vs the MS-Windows system as it comes shrink-wrapped. And that is the comparison I made: I think that Richard was right saying that MS-Windows comes out of the box as a complete and usable system, while GNU/Linux without any GNU program is unusable. You also made some incorrect statements about Windows, both about its usability without ports of GNU software, and wrt our ability to clearly define what is the equivalent of the Linux kernel on Windows. The cause of Free Software is not served well by concealing the truth behind tricky argument techniques and over-simplified statements. It is better served by looking the hard facts in the face and stating our principles even if the reality is not as simple as we'd wish it to be. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-28 10:49 ` Eli Zaretskii @ 2006-10-29 18:45 ` Richard Stallman 2006-10-29 20:19 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Richard Stallman @ 2006-10-29 18:45 UTC (permalink / raw) Cc: emacs-devel GNU/Linux is called that way because without GNU programs that system is unusable, even though more than half of what comes with the system are not GNU programs. That's not the reason we cite, though. See http://www.gnu.org/gnu/linux-and-gnu.html. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-29 18:45 ` Richard Stallman @ 2006-10-29 20:19 ` Eli Zaretskii 2006-10-30 19:16 ` Richard Stallman 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-29 20:19 UTC (permalink / raw) Cc: emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: dak@gnu.org, emacs-devel@gnu.org > Date: Sun, 29 Oct 2006 13:45:53 -0500 > > GNU/Linux is called that way because without GNU programs that system > is unusable, even though more than half of what comes with the system > are not GNU programs. > > That's not the reason we cite, though. > See http://www.gnu.org/gnu/linux-and-gnu.html. What I said is my reading of what that page says. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-29 20:19 ` Eli Zaretskii @ 2006-10-30 19:16 ` Richard Stallman 2006-10-30 20:49 ` Eli Zaretskii 0 siblings, 1 reply; 75+ messages in thread From: Richard Stallman @ 2006-10-30 19:16 UTC (permalink / raw) Cc: emacs-devel > GNU/Linux is called that way because without GNU programs that system > is unusable, even though more than half of what comes with the system > are not GNU programs. > > That's not the reason we cite, though. > See http://www.gnu.org/gnu/linux-and-gnu.html. What I said is my reading of what that page says. The page must be unclear. Off the list, can we talk to figure out why? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-30 19:16 ` Richard Stallman @ 2006-10-30 20:49 ` Eli Zaretskii 0 siblings, 0 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-10-30 20:49 UTC (permalink / raw) Cc: emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: dak@gnu.org, emacs-devel@gnu.org > Date: Mon, 30 Oct 2006 14:16:08 -0500 > > > GNU/Linux is called that way because without GNU programs that system > > is unusable, even though more than half of what comes with the system > > are not GNU programs. > > > > That's not the reason we cite, though. > > See http://www.gnu.org/gnu/linux-and-gnu.html. > > What I said is my reading of what that page says. > > The page must be unclear. Off the list, can we talk to figure out why? Sure. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 10:24 ` David Kastrup 2006-10-26 15:06 ` Eli Zaretskii @ 2006-10-26 20:40 ` Richard Stallman 2006-10-26 20:58 ` David Kastrup 1 sibling, 1 reply; 75+ messages in thread From: Richard Stallman @ 2006-10-26 20:40 UTC (permalink / raw) Cc: emacs-devel Microsoft Windows is not a complete system, as it is missing most end user applications, and is also lacking the toolbox inventory of small utilities that are a necessary ingredient of POSIX systems. One has to add quite a bit of GNU stuff to MS Windows before it becomes comparably useful. I stand corrected. Nonetheless, isn't it a lot more than a kernel? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 20:40 ` Richard Stallman @ 2006-10-26 20:58 ` David Kastrup 0 siblings, 0 replies; 75+ messages in thread From: David Kastrup @ 2006-10-26 20:58 UTC (permalink / raw) Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > Microsoft Windows is not a complete system, as it is missing most end > user applications, and is also lacking the toolbox inventory of small > utilities that are a necessary ingredient of POSIX systems. > > One has to add quite a bit of GNU stuff to MS Windows before it > becomes comparably useful. > > I stand corrected. Nonetheless, isn't it a lot more than a kernel? Yes. The lines between kernel and non-kernel are partly drawn differently than in typical POSIX systems (for example, with the whole graphics subsystem running in supervisor mode), and system services and kernels are not separated in a similar way to other system (I seem to remember that the distinction between kernel thread and daemon is not as absolute, but might be mistaken). The basic design for Windows NT/2000/XP (I think) is supposed to be microkernel-based to some degree, whereas the 95/98/ME family is based on an old DOS kernel with both 32bit and graphical extensions. The system "as such" contains quite more than the kernel, that much is true. It is just hard to tell what is kernel and what not: running in supervisor mode does not really seem like the absolute criterion. And the system "as such" has not as much "hands-on" usefulness for doing non-trivial tasks than a typical Unix or lookalike, let alone a GNU/Linux distribution. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 8:21 ` Angelo Graziosi 2006-10-26 8:57 ` Jason Rumney 2006-10-26 10:12 ` Building Emacs-cvs on Cygwin Richard Stallman @ 2006-10-26 15:12 ` Eli Zaretskii 2006-10-26 16:18 ` Angelo Graziosi 2 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-26 15:12 UTC (permalink / raw) Cc: emacs-devel, storm > Date: Thu, 26 Oct 2006 10:21:16 +0200 (MET DST) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: storm@cua.dk, emacs-devel@gnu.org > > I had a build tree (CVS 20061025 15:00) on Linux, so I have run > > make distclean > > then I have packed the tree and tranfered it on Window-Cygwin. > > Here I have updated CVS and added a pointer to GCC-4.0.3 bin dir > > export PATH=/usr/local/g95/bin:$PATH > gcc -v > > in the build script for Emacs-CVS. > > This script run > > ... > ../configure --prefix=... > make > cd lisp > make autoloads EMACS=../src/emacs > make recompile EMACS=../src/emacs > cd .. > make > make install > > > This Emacs-CVS build seems to run without any crashing! This is good to know, but the above doesn't produce bootstrap-emacs at any point and doesn't run it; it uses the *.elc files compiled on GNU/Linux. So it sounds like the crashes are unique to bootstrap-emacs, which means users will be able to build the released tarball, but still leaves the question of why the bootstrap failed unanswered. Please see if your *.elc files produced by the bootstrap are in DOS CRLF format, which, as Jason points out, was known to cause crashes in the past. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 15:12 ` Eli Zaretskii @ 2006-10-26 16:18 ` Angelo Graziosi 0 siblings, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-10-26 16:18 UTC (permalink / raw) Cc: Angelo Graziosi, emacs-devel, storm The builds with GCC-3.4.4-2 segment faults regardless if they are bootstrapped or with the method schetched below. The last useful build with GCC-3.4.4-2 is with CVS dated 20060906 13:50. After this time and until 20060920 06:55 the build fails. Then from 20060920 06:57 the build is fine but Emacs segment faults. (I used the hybrid method because on GNU/Linux the build takes about 0.5 hours while on Cygwin it takes about 2.5 - 3.0 hours, so with this 'hybrid' build I have cutted the times). I have examined the *.elc file, those produced on GNU/Linux and on Cygwin. There are a few of them (e.g button.elc) that Crimson editor indicates as in DOS format (those produced on GNU/Linux too), but when loaded with Emacs I see only -=:-- and not (DOS). In any case the only differences, I found, are the compile time, name of machine, building dir. When stripped of these things they, on GNU/Linux and Cygwin, have the same size. Angelo. On Thu, 26 Oct 2006, Eli Zaretskii wrote: > > Date: Thu, 26 Oct 2006 10:21:16 +0200 (MET DST) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > cc: storm@cua.dk, emacs-devel@gnu.org > > > > I had a build tree (CVS 20061025 15:00) on Linux, so I have run > > > > make distclean > > > > then I have packed the tree and tranfered it on Window-Cygwin. > > > > Here I have updated CVS and added a pointer to GCC-4.0.3 bin dir > > > > export PATH=/usr/local/g95/bin:$PATH > > gcc -v > > > > in the build script for Emacs-CVS. > > > > This script run > > > > ... > > ../configure --prefix=... > > make > > cd lisp > > make autoloads EMACS=../src/emacs > > make recompile EMACS=../src/emacs > > cd .. > > make > > make install > > > > > > This Emacs-CVS build seems to run without any crashing! > > This is good to know, but the above doesn't produce bootstrap-emacs at > any point and doesn't run it; it uses the *.elc files compiled on > GNU/Linux. So it sounds like the crashes are unique to > bootstrap-emacs, which means users will be able to build the released > tarball, but still leaves the question of why the bootstrap failed > unanswered. > > Please see if your *.elc files produced by the bootstrap are in DOS > CRLF format, which, as Jason points out, was known to cause crashes in > the past. > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-25 22:32 ` Angelo Graziosi 2006-10-26 7:48 ` Eli Zaretskii @ 2006-10-26 8:53 ` Richard Stallman 2006-10-26 15:08 ` Eli Zaretskii 1 sibling, 1 reply; 75+ messages in thread From: Richard Stallman @ 2006-10-26 8:53 UTC (permalink / raw) Cc: eliz, storm, emacs-devel i.e. GCC-4.0.3, 4.3.0 (and also 3.4.4-1) works correctly with GDB but not GCC-3.4.4-2 (exp. package in Cygwin, it applies the '24196' patch) which I used to build hello.c and Emacs-cvs. For some strange reason, using '-g' with GCC-3.4.4-2 does not insert the right debug symbols in the executable. If an old version has a bug that has been fixed, the solution is simple: upgrade GCC. Eli, would you like to document this in the appropriate place? Perhaps etc/PROBLEMS, or wherever there are Cygwin build instructions. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 8:53 ` Richard Stallman @ 2006-10-26 15:08 ` Eli Zaretskii 2006-10-27 9:10 ` Richard Stallman 0 siblings, 1 reply; 75+ messages in thread From: Eli Zaretskii @ 2006-10-26 15:08 UTC (permalink / raw) Cc: Angelo.Graziosi, storm, emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: eliz@gnu.org, emacs-devel@gnu.org, storm@cua.dk > Date: Thu, 26 Oct 2006 04:53:04 -0400 > > Eli, would you like to document this in the appropriate place? > Perhaps etc/PROBLEMS, or wherever there are Cygwin build instructions. I'm not yet sure what to say there, since we don't yet know whether the bootstrap worked with the newer version of GCC. What we do know for sure is that the older version didn't produce correct debug info, but that is only marginally relevant to Emacs, more to GDB. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-10-26 15:08 ` Eli Zaretskii @ 2006-10-27 9:10 ` Richard Stallman 0 siblings, 0 replies; 75+ messages in thread From: Richard Stallman @ 2006-10-27 9:10 UTC (permalink / raw) Cc: Angelo.Graziosi, storm, emacs-devel I'm not yet sure what to say there, since we don't yet know whether the bootstrap worked with the newer version of GCC. You can say that newer versions give correct debugging output, so people using GCC 3.4 should upgrade. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Problems with 'make install' after the build of Emacs-cvs on Cygwin 2006-09-30 14:47 ` Eli Zaretskii 2006-09-30 16:49 ` Angelo Graziosi @ 2006-09-30 17:00 ` Angelo Graziosi 2006-10-02 0:30 ` Giorgos Keramidas 1 sibling, 1 reply; 75+ messages in thread From: Angelo Graziosi @ 2006-09-30 17:00 UTC (permalink / raw) Cc: emacs-devel, storm Hi Eli, While conserving the tree of previous build of Emacs so that we can try to debug its segm. faults, I have tried a new build fram a new CVS downloaded after: 2006-09-30 Eli Zaretskii <eliz@gnu.org> * configure: Regenerated. But when 'make install' there are the following problems: -------------------------------------------------------- ... cd leim; make install make[1]: Entering directory `/tmp/emacs/.build/leim' ... /bin/sh: line 0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No such file or directory /bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory Copying leim files to /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim ... /bin/sh: line 13: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No such file or directory leim-list.el quail/ quail/4Corner.el tar: quail/4Corner.el: Cannot open: Permission denied tar: Skipping to next header quail/4Corner.elc tar: quail/4Corner.elc: Cannot open: Permission denied tar: Skipping to next header quail/ARRAY30.el tar: quail/ARRAY30.el: Cannot open: Permission denied tar: Skipping to next header quail/ARRAY30.elc tar: quail/ARRAY30.elc: Cannot open: Permission denied tar: Skipping to next header ... Many ... tar: quail: file changed as we read it tar: Error exit delayed from previous errors /bin/sh: line 16: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No such file or directory quail/CVS/ quail/CVS/Entries ... -------------------------------------------------------- In the ChangeLog I note ----------------------------------------------------------------- 2006-09-28 Kenichi Handa <handa@m17n.org> * configure.in (locallisppath): Don't include leim dir. (lisppath): Include leim dir. ------------------------------------------------------------------ Could it be the cause ? Cheers, Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problems with 'make install' after the build of Emacs-cvs on Cygwin 2006-09-30 17:00 ` Problems with 'make install' after the build of " Angelo Graziosi @ 2006-10-02 0:30 ` Giorgos Keramidas 2006-10-02 12:53 ` Kenichi Handa 0 siblings, 1 reply; 75+ messages in thread From: Giorgos Keramidas @ 2006-10-02 0:30 UTC (permalink / raw) Cc: Eli Zaretskii, storm, emacs-devel On 2006-09-30 19:00, Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> wrote: > > Hi Eli, > > While conserving the tree of previous build of Emacs so that we can try to > debug its segm. faults, I have tried a new build fram a new CVS downloaded > after: > > 2006-09-30 Eli Zaretskii <eliz@gnu.org> > > * configure: Regenerated. > > But when 'make install' there are the following problems: > -------------------------------------------------------- > ... > cd leim; make install > make[1]: Entering directory `/tmp/emacs/.build/leim' > ... > /bin/sh: line > 0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No > such file or directory > /bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory > Copying leim files to > /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim ... > /bin/sh: line > 13: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No > such file or directory > leim-list.el I had to add `mkinstalldirs' to leim/ too to make Emacs build successfully from a snapshot obtained from CVS at: % $ hg tip % changeset: 76412:6d04f2749c12 % tag: tip % user: eliz % date: Sun Oct 01 17:11:58 2006 +0000 % summary: *** empty log message *** % % $ The diff from the local Mercurial tree I use to keep my own changes is: %%% # HG changeset patch # User Giorgos Keramidas <keramida@ceid.upatras.gr> # Date 1159748821 -10800 # Node ID dc7359535a0eb4664d13cff02c848b614ddb0dc1 # Parent 73911f55ac5ecf415cc729f549ad9a47f61ffe57 Add `mkinstalldirs' to leim/ too, now that it needs it. diff -r 73911f55ac5e -r dc7359535a0e leim/mkinstalldirs --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/leim/mkinstalldirs Mon Oct 02 03:27:01 2006 +0300 @@ -0,0 +1,38 @@ +#! /bin/sh +# mkinstalldirs --- make directory hierarchy +# Author: Noah Friedman <friedman@prep.ai.mit.edu> +# Created: 1993-05-16 +# Public domain + +errstatus=0 + +for file +do + set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'` + shift + + pathcomp= + for d + do + pathcomp="$pathcomp$d" + case "$pathcomp" in + -* ) pathcomp=./$pathcomp ;; + esac + + if test ! -d "$pathcomp"; then + echo "mkdir $pathcomp" 1>&2 + + mkdir "$pathcomp" || lasterr=$? + + if test ! -d "$pathcomp"; then + errstatus=$lasterr + fi + fi + + pathcomp="$pathcomp/" + done +done + +exit $errstatus + +# mkinstalldirs ends here %%% ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problems with 'make install' after the build of Emacs-cvs on Cygwin 2006-10-02 0:30 ` Giorgos Keramidas @ 2006-10-02 12:53 ` Kenichi Handa 2006-10-02 13:39 ` Giorgos Keramidas 0 siblings, 1 reply; 75+ messages in thread From: Kenichi Handa @ 2006-10-02 12:53 UTC (permalink / raw) Cc: eliz, Angelo.Graziosi, emacs-devel, storm In article <20061002003033.GA80773@gothmog.pc>, Giorgos Keramidas <keramida@ceid.upatras.gr> writes: > On 2006-09-30 19:00, Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> wrote: > > > > Hi Eli, > > > > While conserving the tree of previous build of Emacs so that we can try to > > debug its segm. faults, I have tried a new build fram a new CVS downloaded > > after: > > > > 2006-09-30 Eli Zaretskii <eliz@gnu.org> > > > > * configure: Regenerated. > > > > But when 'make install' there are the following problems: > > -------------------------------------------------------- > > ... > > cd leim; make install > > make[1]: Entering directory `/tmp/emacs/.build/leim' > > ... > > /bin/sh: line > > 0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No > > such file or directory > > /bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory Oops, sorry, it's my fault. I've just installed the attached change. --- Kenichi Handa handa@m17n.org Index: Makefile.in =================================================================== RCS file: /cvsroot/emacs/emacs/leim/Makefile.in,v retrieving revision 1.76 retrieving revision 1.77 diff -u -r1.76 -r1.77 --- Makefile.in 28 Sep 2006 05:46:00 -0000 1.76 +++ Makefile.in 2 Oct 2006 12:39:18 -0000 1.77 @@ -221,7 +221,7 @@ rm -rf ${INSTALLDIR}/leim-list.el; \ rm -rf ${INSTALLDIR}/quail ${INSTALLDIR}/ja-dic ; \ else \ - ${srcdir}/mkinstalldirs ${INSTALLDIR}; \ + ${srcdir}/${dot}${dot}/mkinstalldirs ${INSTALLDIR}; \ fi; \ echo "Copying leim files to ${INSTALLDIR} ..." ; \ if [ x`(cd ${srcdir} && /bin/pwd)` = x`(/bin/pwd)` ] ; then \ ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problems with 'make install' after the build of Emacs-cvs on Cygwin 2006-10-02 12:53 ` Kenichi Handa @ 2006-10-02 13:39 ` Giorgos Keramidas 0 siblings, 0 replies; 75+ messages in thread From: Giorgos Keramidas @ 2006-10-02 13:39 UTC (permalink / raw) Cc: eliz, Angelo.Graziosi, emacs-devel, storm On 2006-10-02 21:53, Kenichi Handa <handa@m17n.org> wrote: >In article <20061002003033.GA80773@gothmog.pc>, Giorgos Keramidas <keramida@ceid.upatras.gr> writes: >>On 2006-09-30 19:00, Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> wrote: >>> >>> Hi Eli, >>> >>> While conserving the tree of previous build of Emacs so that we can try to >>> debug its segm. faults, I have tried a new build fram a new CVS downloaded >>> after: >>> >>> 2006-09-30 Eli Zaretskii <eliz@gnu.org> >>> >>> * configure: Regenerated. >>> >>> But when 'make install' there are the following problems: >>> -------------------------------------------------------- >>> ... >>> cd leim; make install >>> make[1]: Entering directory `/tmp/emacs/.build/leim' >>> ... >>> /bin/sh: line >>> 0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No >>> such file or directory >>> /bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory > > Oops, sorry, it's my fault. I've just installed the > attached change. No problem. Thanks for the quick fix :) > Index: Makefile.in > =================================================================== > RCS file: /cvsroot/emacs/emacs/leim/Makefile.in,v > retrieving revision 1.76 > retrieving revision 1.77 > diff -u -r1.76 -r1.77 > --- Makefile.in 28 Sep 2006 05:46:00 -0000 1.76 > +++ Makefile.in 2 Oct 2006 12:39:18 -0000 1.77 > @@ -221,7 +221,7 @@ > rm -rf ${INSTALLDIR}/leim-list.el; \ > rm -rf ${INSTALLDIR}/quail ${INSTALLDIR}/ja-dic ; \ > else \ > - ${srcdir}/mkinstalldirs ${INSTALLDIR}; \ > + ${srcdir}/${dot}${dot}/mkinstalldirs ${INSTALLDIR}; \ > fi; \ > echo "Copying leim files to ${INSTALLDIR} ..." ; \ > if [ x`(cd ${srcdir} && /bin/pwd)` = x`(/bin/pwd)` ] ; then \ ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-30 9:30 ` Eli Zaretskii 2006-09-30 10:16 ` Angelo Graziosi @ 2006-09-30 23:34 ` Kim F. Storm 2006-10-01 10:28 ` Eli Zaretskii 1 sibling, 1 reply; 75+ messages in thread From: Kim F. Storm @ 2006-09-30 23:34 UTC (permalink / raw) Cc: Angelo Graziosi, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Date: Thu, 28 Sep 2006 12:18:00 +0200 (MET DST) >> From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> >> cc: storm@cua.dk, emacs-devel@gnu.org >> >> The problem is localized between lines >> >> >> 1072 # People get bothered when... >> ..... ..... >> >> 1110 end > > This is somewhat tangential to the real problem at hand, but as long > as we are talking about this: what happens if you remove all that > block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and > then manually type the commands in the offending block, one after the > other? I'm particularly interested to know whether you see any error > messages from GDB, and if so, which line causes these messages. > >> (gdb) xpr >> Lisp_Symbol >> $2 = (struct Lisp_Symbol *) 0x7d8bf888 >> Cannot access memory at address 0x7d8bf88c >> (gdb) > > Kim, any clever ideas, before we ask Angelo to look in last_marked[] > array etc.? Turning off the toolbar makes the crash go away, so I suspect a GC problem with building the tool-bar string. It could be a specific tool-bar binding in one of the keymaps that triggers the bug. Could we try to dump global-map, and all active local maps and look for tool-bar items (using eval) in them ? Does Cygwin use GCPROs or stack marking? > >> I want to flag that on Cygwin mailing list there are peoples that have >> similar problems with GDB >> (http://cygwin.com/ml/cygwin/2006-09/msg00534.html). > > Yes, I've seen that thread, but I don't see any useful (i.e., that > explain what's going on and why) responses to the problem it reported. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-30 23:34 ` Building " Kim F. Storm @ 2006-10-01 10:28 ` Eli Zaretskii 0 siblings, 0 replies; 75+ messages in thread From: Eli Zaretskii @ 2006-10-01 10:28 UTC (permalink / raw) Cc: Angelo.Graziosi, emacs-devel > Cc: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it>, emacs-devel@gnu.org > From: storm@cua.dk (Kim F. Storm) > Date: Sun, 01 Oct 2006 01:34:37 +0200 > > Could we try to dump global-map, and all active local maps and look > for tool-bar items (using eval) in them ? > > Does Cygwin use GCPROs or stack marking? Please instruct Angelo how to find the answers to these questions. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-26 20:10 ` Eli Zaretskii 2006-09-26 22:18 ` Angelo Graziosi 2006-09-27 16:52 ` Angelo Graziosi @ 2006-09-27 18:14 ` Angelo Graziosi 2 siblings, 0 replies; 75+ messages in thread From: Angelo Graziosi @ 2006-09-27 18:14 UTC (permalink / raw) Cc: emacs-devel, storm On Tue, 26 Sep 2006, Eli Zaretskii wrote: > If none of the above helps get rid of the hang, try to edit the file > src/.gdbinit so that it is left only with definitions of commands > (each definition is a block that starts with "define" and ends with > "end") and their documentation (blocks that start with "document"), > and remove everything else. Done! This is the result: ------------------------------------------------------------------ cd /tmp/emacs/.build/src $ gdb ./emacs.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) r Starting program: /tmp/emacs/.build/src/emacs.exe Loaded symbols for /c/WINDOWS/system32/ntdll.dll Loaded symbols for /c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/X11R6/bin/cygICE-6.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /c/WINDOWS/system32/advapi32.dll Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/X11R6/bin/cygSM-6.dll Loaded symbols for /usr/X11R6/bin/cygX11-6.dll Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll Loaded symbols for /usr/X11R6/bin/cygXext-6.dll Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll Loaded symbols for /usr/X11R6/bin/cygXt-6.dll Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /usr/bin/cygjpeg-62.dll Loaded symbols for /usr/bin/cygpng12.dll Loaded symbols for /usr/bin/cygz.dll Loaded symbols for /usr/bin/cygtiff-5.dll Loaded symbols for /usr/bin/cygungif-4.dll warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] [1]+ Stopped gdb ./emacs.exe $ fg gdb ./emacs.exe ---Type <return> to continue, or q <return> to quit--- ---------------------------------------------------------------- after a few minutes ---------------------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x200f217c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 5509 MARK_INTERVAL_TREE (ptr->intervals); (gdb) bt #0 0x200f217c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 #1 0x200f2a4f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 #2 0x20106533 in Feval (form=572762717) at /tmp/emacs/src/eval.c:2216 #3 0x20105355 in internal_condition_case_1 (bfun=0x20106490 <Feval>, arg=572762717, handlers=539914913, hfun=0x200a4710 <menu_item_eval_property_1>) at /tmp/emacs/src/eval.c:1525 #4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217) at /tmp/emacs/src/keyboard.c:7270 #5 0x200b0d4e in get_keyelt (object=540146505, autoload=1) at /tmp/emacs/src/keymap.c:829 #6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2, noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655 #7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b698) at /tmp/emacs/src/keyboard.c:7732 #8 0x2001d51f in update_tool_bar (f=0x21933e00, save_match_data=0) at /tmp/emacs/src/xdisp.c:9414 #9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098 #10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217) at /tmp/emacs/src/xdisp.c:10935 #11 0x2002d08a in redisplay_preserve_echo_area (from_where=8) at /tmp/emacs/src/xdisp.c:11545 #12 0x200a7aec in detect_input_pending_run_timers (do_display=1) at /tmp/emacs/src/keyboard.c:10061 ---Type <return> to continue, or q <return> to quit--- #13 0x2013a2a5 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0, just_wait_proc=0) at /tmp/emacs/src/process.c:4665 #14 0x200a8e40 in read_char (commandflag=1, nmaps=2, maps=0x22c710, prev_event=539858945, used_mouse_menu=0x22c758, end_time=0x0) at /tmp/emacs/src/keyboard.c:3988 #15 0x200ab88d in read_key_sequence (keybuf=0x22c8b0, bufsize=30, prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956 #16 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601 #17 0x2010558f in internal_condition_case (bfun=0x200ad220 <command_loop_1>, handlers=539914913, hfun=0x200a6c80 <cmd_error>) at /tmp/emacs/src/eval.c:1477 #18 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326 #19 0x2010524f in internal_catch (tag=1569454217, func=0x200a0a60 <command_loop_2>, arg=539858945) at /tmp/emacs/src/eval.c:1218 #20 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305 #21 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003 #22 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064 #23 0x2009fd9d in main (argc=1, argv=0x202ce840) at /tmp/emacs/src/emacs.c:1794 (gdb) p arg $1 = 1569454217 (gdb) xpr Lisp_Symbol $2 = (struct Lisp_Symbol *) 0x7d8bf888 Cannot access memory at address 0x7d8bf88c (gdb) ------------------------------------------------------------------ Angelo. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-25 12:56 ` Angelo Graziosi 2006-09-25 19:57 ` Eli Zaretskii @ 2006-09-25 20:42 ` Kim F. Storm 1 sibling, 0 replies; 75+ messages in thread From: Kim F. Storm @ 2006-09-25 20:42 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: > gdb ./emacs > after a few seconds: > ---------------------------------------------------------- > #0 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 > #1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 > #2 0x201064f3 in Feval (form=570000829) at /tmp/emacs/src/eval.c:2216 > #3 0x20105315 in internal_condition_case_1 (bfun=0x20106450 <Feval>, > arg=570000829, handlers=539914913, > hfun=0x200a4710 <menu_item_eval_property_1>) at > /tmp/emacs/src/eval.c:1525 > #4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217) > at /tmp/emacs/src/keyboard.c:7270 > #5 0x200b0d4e in get_keyelt (object=540146505, autoload=1) > at /tmp/emacs/src/keymap.c:829 > #6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2, > noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655 > #7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b658) > at /tmp/emacs/src/keyboard.c:7732 > #8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0) > at /tmp/emacs/src/xdisp.c:9414 > #9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098 > Then I have retried using 'r -Q': > At this point, after 'return', I have waited more than 20 minutes!!! then So might be something that you load ... > I have loaded some files and used 'M-x compile', and in a few secs: > ---------------------------------------------------------------------- > #0 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509 > #1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174 > #2 0x201064f3 in Feval (form=569215053) at /tmp/emacs/src/eval.c:2216 > #3 0x20105315 in > internal_condition_case_1 (bfun=0x20106450 <Feval>, > arg=569215053, handlers=539914913, > hfun=0x200a4710 <menu_item_eval_property_1>) at > /tmp/emacs/src/eval.c:1525 > #4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217) > at /tmp/emacs/src/keyboard.c:7270 > #5 0x200b0d4e in get_keyelt (object=540146505, autoload=1) > at /tmp/emacs/src/keymap.c:829 > #6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2, > noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655 > #7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b648) > at /tmp/emacs/src/keyboard.c:7732 > #8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0) > at /tmp/emacs/src/xdisp.c:9414 > #9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098 The strange thing here is that the crash happens in the same context both times, that it is the same sexpr which is being evalled when it happens, _and_ it is that very same object (sexpr) which is being marked in both cases. So we need to track down what that object is and where it came from. Can you try to debug that using the following gdb commands: p arg xpr (and if possible, expand on the value depending on what type of object it is). Also, can you try to disable the tool-bar and see if the problem still happens. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-23 10:33 ` Building Emacs-cvs on Cygwin Angelo Graziosi 2006-09-23 15:15 ` Eli Zaretskii @ 2006-09-24 2:10 ` Richard Stallman 1 sibling, 0 replies; 75+ messages in thread From: Richard Stallman @ 2006-09-24 2:10 UTC (permalink / raw) Cc: eliz, emacs-devel Maybe you are right, but why would GDB care whether it was compiled with debugging symbols? And how could it know? ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Building Emacs-cvs on Cygwin 2006-09-20 9:05 ` Angelo Graziosi 2006-09-20 21:08 ` Eli Zaretskii @ 2006-09-21 1:59 ` Richard Stallman 1 sibling, 0 replies; 75+ messages in thread From: Richard Stallman @ 2006-09-21 1:59 UTC (permalink / raw) Cc: eliz, emacs-devel > > This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think this refers to GDB (even with CFLAGS='-g' I obtain it, see below) It refers to the program you are debugging. GDB has already tried to read that executable, and failed. /tmp/emacs/src/.gdbinit:1089: Error in sourced command file: No struct type named Lisp_Symbol. Further proof of the same problem. ^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2006-10-30 20:49 UTC | newest] Thread overview: 75+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-09-19 23:49 Building Emacs-cvs on Cygwin Angelo Graziosi 2006-09-20 3:29 ` Eli Zaretskii 2006-09-20 9:05 ` Angelo Graziosi 2006-09-20 21:08 ` Eli Zaretskii 2006-09-20 22:02 ` Andreas Schwab 2006-09-20 22:41 ` Building Emacs-cvs on Cygwin (Mystery!) Angelo Graziosi 2006-09-21 3:31 ` Eli Zaretskii 2006-09-21 22:20 ` Angelo Graziosi 2006-09-22 13:19 ` Eli Zaretskii 2006-09-22 23:08 ` Angelo Graziosi 2006-09-22 23:22 ` Angelo Graziosi 2006-09-24 13:02 ` Angelo Graziosi 2006-09-23 10:33 ` Building Emacs-cvs on Cygwin Angelo Graziosi 2006-09-23 15:15 ` Eli Zaretskii 2006-09-23 16:49 ` Angelo Graziosi 2006-09-23 19:17 ` Eli Zaretskii 2006-09-23 21:19 ` Angelo Graziosi 2006-09-24 7:41 ` Eli Zaretskii 2006-09-24 22:46 ` Angelo Graziosi 2006-09-25 3:26 ` Eli Zaretskii 2006-09-25 12:56 ` Angelo Graziosi 2006-09-25 19:57 ` Eli Zaretskii 2006-09-26 0:06 ` Angelo Graziosi 2006-09-26 3:22 ` Eli Zaretskii 2006-09-26 12:48 ` Angelo Graziosi 2006-09-26 20:10 ` Eli Zaretskii 2006-09-26 22:18 ` Angelo Graziosi 2006-09-27 3:35 ` Eli Zaretskii 2006-09-27 16:52 ` Angelo Graziosi 2006-09-27 18:22 ` Eli Zaretskii 2006-09-28 10:18 ` Angelo Graziosi 2006-09-30 9:30 ` Eli Zaretskii 2006-09-30 10:16 ` Angelo Graziosi 2006-09-30 14:47 ` Eli Zaretskii 2006-09-30 16:49 ` Angelo Graziosi 2006-10-01 16:54 ` Eli Zaretskii 2006-10-01 21:29 ` Angelo Graziosi 2006-10-25 22:32 ` Angelo Graziosi 2006-10-26 7:48 ` Eli Zaretskii 2006-10-26 8:21 ` Angelo Graziosi 2006-10-26 8:57 ` Jason Rumney 2006-10-26 15:46 ` Angelo Graziosi 2006-10-27 8:41 ` Eli Zaretskii 2006-10-27 16:34 ` Angelo Graziosi 2006-10-28 0:16 ` Angelo Graziosi 2006-10-28 12:16 ` Eli Zaretskii 2006-10-29 11:13 ` Building Emacs-cvs on Cygwin (GCC summary) Angelo Graziosi 2006-10-26 10:12 ` Building Emacs-cvs on Cygwin Richard Stallman 2006-10-26 10:24 ` David Kastrup 2006-10-26 15:06 ` Eli Zaretskii 2006-10-26 15:12 ` David Kastrup 2006-10-27 8:17 ` Eli Zaretskii 2006-10-27 9:04 ` David Kastrup 2006-10-28 10:49 ` Eli Zaretskii 2006-10-29 18:45 ` Richard Stallman 2006-10-29 20:19 ` Eli Zaretskii 2006-10-30 19:16 ` Richard Stallman 2006-10-30 20:49 ` Eli Zaretskii 2006-10-26 20:40 ` Richard Stallman 2006-10-26 20:58 ` David Kastrup 2006-10-26 15:12 ` Eli Zaretskii 2006-10-26 16:18 ` Angelo Graziosi 2006-10-26 8:53 ` Richard Stallman 2006-10-26 15:08 ` Eli Zaretskii 2006-10-27 9:10 ` Richard Stallman 2006-09-30 17:00 ` Problems with 'make install' after the build of " Angelo Graziosi 2006-10-02 0:30 ` Giorgos Keramidas 2006-10-02 12:53 ` Kenichi Handa 2006-10-02 13:39 ` Giorgos Keramidas 2006-09-30 23:34 ` Building " Kim F. Storm 2006-10-01 10:28 ` Eli Zaretskii 2006-09-27 18:14 ` Angelo Graziosi 2006-09-25 20:42 ` Kim F. Storm 2006-09-24 2:10 ` Richard Stallman 2006-09-21 1:59 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.