Building Emacs-cvs on Cygwin

Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

> 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?

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Andreas Schwab]

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."

Re: Building Emacs-cvs on Cygwin (Mystery!)

[Angelo Graziosi]

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

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

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

Re: Building Emacs-cvs on Cygwin (Mystery!)

[Eli Zaretskii]

> 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?

Re: Building Emacs-cvs on Cygwin (Mystery!)

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin (Mystery!)

[Eli Zaretskii]

> 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?

Re: Building Emacs-cvs on Cygwin (Mystery!)

[Angelo Graziosi]

[-- 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

Re: Building Emacs-cvs on Cygwin (Mystery!)

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

> 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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

> 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?

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

Maybe you are right, but why would GDB care whether it was compiled
with debugging symbols?  And how could it know?

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

> 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.)

Re: Building Emacs-cvs on Cygwin (Mystery!)

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Kim F. Storm]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

> 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?

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

> 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).

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Problems with 'make install' after the build of Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Kim F. Storm]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Problems with 'make install' after the build of Emacs-cvs on Cygwin

[Giorgos Keramidas]

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
%%%

Re: Problems with 'make install' after the build of Emacs-cvs on Cygwin

[Kenichi Handa]

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 \

Re: Problems with 'make install' after the build of Emacs-cvs on Cygwin

[Giorgos Keramidas]

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 \

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

> 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?

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

    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.

Re: Building Emacs-cvs on Cygwin

[Jason Rumney]

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.

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

    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.

Re: Building Emacs-cvs on Cygwin

[David Kastrup]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[David Kastrup]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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. 

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

    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?

Re: Building Emacs-cvs on Cygwin

[David Kastrup]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[David Kastrup]

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

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

    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.

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin (GCC summary)

[Angelo Graziosi]

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.

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

    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.

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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

Re: Building Emacs-cvs on Cygwin

[Richard Stallman]

    >     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?

Re: Building Emacs-cvs on Cygwin

[Eli Zaretskii]

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