unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* DJGPP only dumps with USE_LISP_UNION_TYPE ??
@ 2004-11-07 10:13 Jan D.
  2004-11-07 10:50 ` Andreas Schwab
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Jan D. @ 2004-11-07 10:13 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

Hello.

I was trying to get Emacs to compile on djgpp 2.03.  But it crashed 
every time in the dump phase, at the first GC.  I tried different gcc 
versions (2.95, 3.22, 3.42), different binutils versions (2.11, 2.15), 
with and without optimizations, with and without debugging but it 
always crashed at the same spot.  Since it crashed in GC, I tried to 
set the USE_LISP_UNION_TYPE (found a couple of errors and checked them 
in), and to my surprise, I got a working Emacs.

Does this sound familiar to anyone?  Shouldn't with and without 
USE_LISP_UNION_TYPE be the same at runtime?  I was wondering if this 
could happen at other systems besides djgpp, and if there is some 
subtle Lisp_Object handling bug somewhere.  I've attached some 
debugging output.  If anyone has any idea and want more debugging done, 
I can provide it.

Thanks,

	Jan D.

[-- Attachment #2: symify.out --]
[-- Type: application/octet-stream, Size: 2099 bytes --]

stubedit temacs.exe minstack=100k
set LC_ALL=C; ./temacs -batch -l loadup dump
Loading loadup.el (source)...
Using load-path (../lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version.el (source)...
Loading widget...
Loading custom...
Loading emacs-lisp/map-ynp...
Loading env...
Loading cus-start...
Loading international/mule...
Exiting due to signal SIGABRT
Raised at eip=00168e5e
eax=002f7e5c ebx=00000120 ecx=00000000 edx=00000000 esi=00000054 edi=002dfa78
ebp=002f7f08 esp=002f7e58 program=D:\src\emacsCVS\src\temacs.exe
cs: sel=024f  base=02f30000  limit=003affff
ds: sel=0257  base=02f30000  limit=003affff
es: sel=0257  base=02f30000  limit=003affff
fs: sel=0227  base=00018030  limit=0000ffff
gs: sel=0277  base=00000000  limit=0010ffff
ss: sel=0257  base=02f30000  limit=003affff
App stack: [002f8a78..002dfa78]  Exceptn stack: [002df94c..002dda0c]

Call frame traceback EIPs:
  0x00168d84 ___djgpp_traceback_exit+48
  0x00168e5e _raise+90
  0x00152f3c _abort+55, line 5269 of msdos.c
  0x000de42c _mark_object+2599, line 5122 of alloc.c
  0x000de044 _mark_object+1599, line 4974 of alloc.c
  0x000dd401 _Fgarbage_collect+713, line 4458 of alloc.c
  0x000f946c _Feval+179, line 2015 of eval.c
  0x00114c1d _readevalloop+796, line 1376 of lread.c
  0x00113a8f _Fload+2532, line 914 of lread.c
  0x000f98b4 _Feval+1275, line 2126 of eval.c
  0x00114c1d _readevalloop+796, line 1376 of lread.c
  0x00113a8f _Fload+2532, line 914 of lread.c
  0x000f98b4 _Feval+1275, line 2126 of eval.c
  0x000784cb _top_level_2+20, line 1318 of keyboard.c
  0x000f8259 _internal_condition_case+243, line 1367 of eval.c
  0x0007857f _top_level_1+52, line 1326 of keyboard.c
  0x000f7cc1 _internal_catch+168, line 1128 of eval.c
  0x0007842e _command_loop+101, line 1283 of keyboard.c
  0x00077f3e _recursive_edit_1+118, line 981 of keyboard.c
  0x00078074 _Frecursive_edit+148, line 1043 of keyboard.c
  0x00076390 _main+3459, line 1740 of emacs.c
  0x0015fde8 ___crt1_startup+176
make.exe: *** [emacs] Error -1

[-- Attachment #3: debug.out --]
[-- Type: application/octet-stream, Size: 3710 bytes --]

#0  abort () at msdos.c:5258
#1  0x000de42c in mark_object (arg=-1) at alloc.c:5116
#2  0x000de044 in mark_object (arg=2985636) at alloc.c:4974
#3  0x000dd401 in Fgarbage_collect () at alloc.c:4458
#4  0x000f946c in Feval (form=4071341) at eval.c:2011
#5  0x00114c1d in readevalloop (readcharfun=3676001, stream=0x38c7c0,
    sourcename=4010275, evalfun=0xf93b9 <Feval>, printflag=0, unibyte=3592193,
    readfun=3592193) at lread.c:1376
#6  0x00113a8f in Fload (file=4010275, noerror=3592193, nomessage=3592193,
    nosuffix=3592193, must_suffix=3592193) at lread.c:914
#7  0x000f98b4 in Feval (form=4003557) at eval.c:2126
#8  0x00114c1d in readevalloop (readcharfun=3676001, stream=0x38c8a0,
    sourcename=3806867, evalfun=0xf93b9 <Feval>, printflag=0, unibyte=3592193,
    readfun=3592193) at lread.c:1376
#9  0x00113a8f in Fload (file=3806867, noerror=3592193, nomessage=3592193,
    nosuffix=3592193, must_suffix=3592193) at lread.c:914
#10 0x000f98b4 in Feval (form=3622853) at eval.c:2126
#11 0x000784cb in top_level_2 () at keyboard.c:1318
#12 0x000f8259 in internal_condition_case (bfun=0x784b7 <top_level_2>,
    handlers=3660233, hfun=0x78180 <cmd_error>) at eval.c:1367
#13 0x0007857f in top_level_1 () at keyboard.c:1326
#14 0x000f7cc1 in internal_catch (tag=3657545, func=0x7854b <top_level_1>,
    arg=3592193) at eval.c:1128
#15 0x0007842e in command_loop () at keyboard.c:1283
#16 0x00077f3e in recursive_edit_1 () at keyboard.c:981
#17 0x00078074 in Frecursive_edit () at keyboard.c:1042
#18 0x00076390 in main (argc=5, argv=0x365c80) at emacs.c:1738

#0  abort () at msdos.c:5258
5258      dos_ttcooked ();
(gdb) up
#1  0x000de42c in mark_object (arg=-1) at alloc.c:5116
5116          abort ();
(gdb) l
5111
5112        case Lisp_Int:
5113          break;
5114
5115        default:
5116          abort ();
5117        }
5118
5119    #undef CHECK_LIVE
5120    #undef CHECK_ALLOCATED
(gdb) p obj
$1 = -1
(gdb) up
#2  0x000de044 in mark_object (arg=2985636) at alloc.c:4974
4974                mark_object (ptr->contents[i]);
(gdb) p ptr->contents[i]
$1 = -1
(gdb) l
4969              VECTOR_MARK (ptr);    /* Else mark it */
4970              if (size & PSEUDOVECTOR_FLAG)
4971                size &= PSEUDOVECTOR_SIZE_MASK;
4972
4973              for (i = 0; i < size; i++) /* and then mark its elements */
4974                mark_object (ptr->contents[i]);
4975            }
4976          break;
4977
4978        case Lisp_Symbol:
(gdb) p i
$2 = 40
(gdb) p size
$3 = 3592193
(gdb) up
#3  0x000dd401 in Fgarbage_collect () at alloc.c:4458
4458        mark_object (*staticvec[i]);
(gdb) l
4453      /* clear_marks (); */
4454
4455      /* Mark all the special slots that serve as the roots of accessibility
.  */
4456
4457      for (i = 0; i < staticidx; i++)
4458        mark_object (*staticvec[i]);
4459
4460      for (bind = specpdl; bind != specpdl_ptr; bind++)
4461        {
4462          mark_object (bind->symbol);
(gdb) p i
$1 = 418


...

Breakpoint 2, staticpro (varaddress=0x2cae00) at alloc.c:4315
4315      if (staticidx >= NSTATICS)
(gdb) p staticidx
$1 = 419
(gdb) up
#1  0x0009dc23 in syms_of_buffer () at buffer.c:5192
5192      staticpro (&Vbuffer_local_symbols);
(gdb) l
5187      staticpro (&last_overlay_modification_hooks);
5188      last_overlay_modification_hooks
5189        = Fmake_vector (make_number (10), Qnil);
5190
5191      staticpro (&Vbuffer_defaults);
5192      staticpro (&Vbuffer_local_symbols);
5193      staticpro (&Qfundamental_mode);
5194      staticpro (&Qmode_class);
5195      staticpro (&QSFundamental);
5196      staticpro (&Vbuffer_alist);

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-07 10:13 DJGPP only dumps with USE_LISP_UNION_TYPE ?? Jan D.
@ 2004-11-07 10:50 ` Andreas Schwab
  2004-11-07 12:02   ` Jan D.
  2004-11-07 21:56 ` Eli Zaretskii
  2004-11-08 15:15 ` Stefan
  2 siblings, 1 reply; 28+ messages in thread
From: Andreas Schwab @ 2004-11-07 10:50 UTC (permalink / raw)
  Cc: emacs devel

"Jan D." <jan.h.d@swipnet.se> writes:

> Does this sound familiar to anyone?  Shouldn't with and without
> USE_LISP_UNION_TYPE be the same at runtime?

USE_LISP_UNION_TYPE implies #undef USE_LSB_TAG.  It looks like USE_LSB_TAG
does not work on DJGPP.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-07 10:50 ` Andreas Schwab
@ 2004-11-07 12:02   ` Jan D.
  2004-11-07 22:03     ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Jan D. @ 2004-11-07 12:02 UTC (permalink / raw)
  Cc: emacs devel


> "Jan D." <jan.h.d@swipnet.se> writes:
>
>> Does this sound familiar to anyone?  Shouldn't with and without
>> USE_LISP_UNION_TYPE be the same at runtime?
>
> USE_LISP_UNION_TYPE implies #undef USE_LSB_TAG.  It looks like 
> USE_LSB_TAG
> does not work on DJGPP.


Aha, that is it.  #undef USE_LSB_TAG also produces a working Emacs.  I 
guess we should not use USE_LSB_TAG for DJGPP.  Is it anyone else who 
can dump Emacs with USE_LSB_TAG?  It might be dependent on different 
versions of djgpp.

	Jan D.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-07 10:13 DJGPP only dumps with USE_LISP_UNION_TYPE ?? Jan D.
  2004-11-07 10:50 ` Andreas Schwab
@ 2004-11-07 21:56 ` Eli Zaretskii
  2004-11-07 23:47   ` Jan D.
  2004-11-08 15:15 ` Stefan
  2 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-07 21:56 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 7 Nov 2004 11:13:18 +0100
> 
> I was trying to get Emacs to compile on djgpp 2.03.  But it crashed 
> every time in the dump phase, at the first GC.

Being the maintainer of the DJGPP port of Emacs, I build Emacs with
DJGPP every few days, and I never saw such a crash.  That includes the
current CVS which I just checked out.  This mail is being composed and
sent by an Emacs built from yesterday's CVS.

> I tried different gcc 
> versions (2.95, 3.22, 3.42), different binutils versions (2.11, 2.15), 

I'm using:

  gcc.exe (GCC) 3.3.3
  GNU ld version 2.14 20030612

(but none of the older versions ever crashed for me like that,
either).  My libc.a is a v2.03 with a few patches, but I doubt that
those patches could cause a GC crash.

> I tried set the USE_LISP_UNION_TYPE (found a couple of errors and
> checked them in)

Thanks.  I never tried USE_LISP_UNION_TYPE, and so I'm not surprised
it didn't work at first.

> Does this sound familiar to anyone?  Shouldn't with and without 
> USE_LISP_UNION_TYPE be the same at runtime?  I was wondering if this 
> could happen at other systems besides djgpp, and if there is some 
> subtle Lisp_Object handling bug somewhere.  I've attached some 
> debugging output.  If anyone has any idea and want more debugging done, 
> I can provide it.

I guess you need to provide as much info as possible.  Please begin by
posting a full transcript of the build, starting from "config msdos".
Then I'd like to see your system configuration (what OS and version
etc.)

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-07 12:02   ` Jan D.
@ 2004-11-07 22:03     ` Eli Zaretskii
  0 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-07 22:03 UTC (permalink / raw)
  Cc: schwab, emacs-devel

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 7 Nov 2004 13:02:30 +0100
> Cc: emacs devel <emacs-devel@gnu.org>
> 
> > "Jan D." <jan.h.d@swipnet.se> writes:
> >
> >> Does this sound familiar to anyone?  Shouldn't with and without
> >> USE_LISP_UNION_TYPE be the same at runtime?
> >
> > USE_LISP_UNION_TYPE implies #undef USE_LSB_TAG.  It looks like 
> > USE_LSB_TAG
> > does not work on DJGPP.
> 
> Aha, that is it.  #undef USE_LSB_TAG also produces a working Emacs.  I 
> guess we should not use USE_LSB_TAG for DJGPP.  Is it anyone else who 
> can dump Emacs with USE_LSB_TAG?

I do.  USE_LSB_TAG works in the DJGPP port since 18 May 2004, see the
entry I made on that day in src/ChangeLog (and the related entry from
15 May, 3 days before that).  You should be able to find a thread from
those days in emacs-devel's archives where Stefan helped me to find
and fix the bug that prevented LSB tags usage in the DJGPP port.

> It might be dependent on different versions of djgpp.

My version of DJGPP is the same as yours: 2.03, the latest.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-07 21:56 ` Eli Zaretskii
@ 2004-11-07 23:47   ` Jan D.
  2004-11-08  8:10     ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Jan D. @ 2004-11-07 23:47 UTC (permalink / raw)
  Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Eli Zaretskii wrote:

> 
> I guess you need to provide as much info as possible.  Please begin by
> posting a full transcript of the build, starting from "config msdos".
> Then I'd like to see your system configuration (what OS and version
> etc.)

I checked out a fresh CVS as of 7 November, 23:50.  The lisp files has 
been compiled on GNU/Linux, with make recompile in lisp and then make 
distclean.  The tree was then copied to a dos disk on the same machine 
and MS Windows was booted.  I've attached two files, one with "config 
msdos" output, and one with make output (I did not do any commands in 
between).  The make.txt file has been symified.  Comparing these to the 
ones with USE_LSB_TAG undef:ed shows one difference that might be 
relevant.  Not that I know what it means :-), but it occurs when temacs 
is linked.

d:/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 
0x11102 > 0xffff

The OS is MS Windows XP, service pack 1.

	Jan D.

[-- Attachment #2: config.txt --]
[-- Type: text/plain, Size: 1052 bytes --]

D:\src\emacs>config msdos
Checking whether 'sed' is available...
Checking whether 'rm' is available...
Checking whether 'mv' is available...
Checking whether 'gcc' is available...
Checking what version of DJGPP is installed...
Checking whether 'djecho' is available...
Configuring for DJGPP Version 2 ...
Configuring the source directory...
Configuring the library source directory...
Configuring the manual directory...
Configuring the ELisp manual directory...
Configuring the ELisp Introduction manual directory...
Configuring the lisp directory...
Configuring the leim directory...
Configuring the main directory...
Looking for the GDB init file...
File `src/_gdbinit' created
Looking for the GDB init file...found

D:\src\emacsCVS>gcc -v
Reading specs from d:/djgpp/lib/gcc-lib/djgpp/3.22/specs
Configured with: /devel/gnu/gcc/3.2/gnu/gcc-3.22/configure i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR --disable-nls
Thread model: single
gcc version 3.2.2

D:\src\emacsCVS>ld -V
GNU ld version 2.15
  Supported emulations:
   i386go32

D:\src\emacsCVS>

[-- Attachment #3: make.txt --]
[-- Type: text/plain, Size: 35777 bytes --]

cd lib-src
d:/djgpp/bin/make.exe top_srcdir=d:/src/emacs version="21.3.50"
make.exe[1]: Entering directory `d:/src/emacs/lib-src'
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g -o test-distrib D:/SRC/EMACS/LIB-SRC/test-distrib.c
In file included from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
test-distrib D:/SRC/EMACS/LIB-SRC/testfile
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/make-docfile.c  -o make-docfile
In file included from D:/SRC/EMACS/LIB-SRC/make-docfile.c:38:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/make-docfile.c:38:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/profile.c  -o profile
In file included from D:/SRC/EMACS/LIB-SRC/profile.c:33:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/profile.c:33:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/digest-doc.c  -o digest-doc
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/sorted-doc.c  -o sorted-doc
In file included from D:/SRC/EMACS/LIB-SRC/sorted-doc.c:27:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/sorted-doc.c:27:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/cvtmail.c  -o cvtmail
In file included from D:/SRC/EMACS/LIB-SRC/cvtmail.c:37:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/cvtmail.c:37:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/fakemail.c  -o fakemail
In file included from D:/SRC/EMACS/LIB-SRC/fakemail.c:25:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/fakemail.c:25:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/yow.c  -o yow
In file included from D:/SRC/EMACS/LIB-SRC/yow.c:14:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/yow.c:14:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/hexl.c  -o hexl
In file included from D:/SRC/EMACS/LIB-SRC/hexl.c:21:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/hexl.c:21:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/update-game-score.c 	  -DHAVE_SHARED_GAME_DIR="\"@gamedir@\"" 	   -o update-game-score
In file included from D:/SRC/EMACS/LIB-SRC/update-game-score.c:32:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/update-game-score.c:32:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src  -O2 -g D:/SRC/EMACS/LIB-SRC/getopt.c
In file included from D:/SRC/EMACS/LIB-SRC/getopt.c:30:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/getopt.c:30:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src  -O2 -g D:/SRC/EMACS/LIB-SRC/getopt1.c
In file included from D:/SRC/EMACS/LIB-SRC/getopt1.c:21:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/getopt1.c:21:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src  -O2 -g -DCONFIG_BROKETS -DINHIBIT_STRING_HEADER D:/SRC/EMACS/LIB-SRC/../src/regex.c
In file included from D:/SRC/EMACS/src/regex.c:37:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/src/regex.c:37:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g -DVERSION="\"21.3.50\"" D:/SRC/EMACS/LIB-SRC/etags.c getopt.o getopt1.o regex.o  -o etags
In file included from D:/SRC/EMACS/LIB-SRC/etags.c:57:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/etags.c:57:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g -DCTAGS -DVERSION="\"21.3.50\"" D:/SRC/EMACS/LIB-SRC/etags.c getopt.o getopt1.o regex.o  -o ctags
In file included from D:/SRC/EMACS/LIB-SRC/etags.c:57:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/etags.c:57:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g D:/SRC/EMACS/LIB-SRC/b2m.c  -DVERSION="\"21.3.50\"" 	   getopt.o getopt1.o  -o b2m
In file included from D:/SRC/EMACS/LIB-SRC/b2m.c:23:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/b2m.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -DHAVE_CONFIG_H    -I. -I../src -ID:/SRC/EMACS/LIB-SRC -ID:/SRC/EMACS/LIB-SRC/../src   -O2 -g -DVERSION="\"21.3.50\"" D:/SRC/EMACS/LIB-SRC/ebrowse.c getopt.o getopt1.o  -o ebrowse
In file included from D:/SRC/EMACS/LIB-SRC/ebrowse.c:24:
../src/config.h:1121:1: warning: "bzero" redefined
In file included from ../src/config.h:1055,
                 from D:/SRC/EMACS/LIB-SRC/ebrowse.c:24:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
make.exe[1]: Leaving directory `d:/src/emacs/lib-src'
cd ..
cd src
d:/djgpp/bin/make.exe top_srcdir=d:/src/emacs
make.exe[1]: Entering directory `d:/src/emacs/src'
touch stamp-oldxmenu
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff dispnew.c
In file included from dispnew.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from dispnew.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff frame.c
In file included from frame.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from frame.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff scroll.c
In file included from scroll.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from scroll.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff xdisp.c
In file included from xdisp.c:169:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from xdisp.c:169:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff xmenu.c
In file included from xmenu.c:34:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from xmenu.c:34:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff window.c
In file included from window.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from window.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff charset.c
In file included from charset.c:27:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from charset.c:27:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff coding.c
In file included from coding.c:334:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from coding.c:334:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff category.c
In file included from category.c:26:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from category.c:26:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff ccl.c
In file included from ccl.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from ccl.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff cm.c
In file included from cm.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from cm.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff term.c
In file included from term.c:24:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from term.c:24:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff xfaces.c
In file included from xfaces.c:194:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from xfaces.c:194:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff emacs.c
In file included from emacs.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from emacs.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff keyboard.c
In file included from keyboard.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from keyboard.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff macros.c
In file included from macros.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from macros.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff keymap.c
In file included from keymap.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from keymap.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff sysdep.c
In file included from sysdep.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from sysdep.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff buffer.c
In file included from buffer.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from buffer.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff filelock.c
In file included from filelock.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from filelock.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff insdel.c
In file included from insdel.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from insdel.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff marker.c
In file included from marker.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from marker.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff minibuf.c
In file included from minibuf.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from minibuf.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff fileio.c
In file included from fileio.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from fileio.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff dired.c
In file included from dired.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from dired.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff filemode.c
In file included from filemode.c:20:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from filemode.c:20:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff cmds.c
In file included from cmds.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from cmds.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff casetab.c
In file included from casetab.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from casetab.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff casefiddle.c
In file included from casefiddle.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from casefiddle.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff indent.c
In file included from indent.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from indent.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff search.c
In file included from search.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from search.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff regex.c
In file included from regex.c:37:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from regex.c:37:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff undo.c
In file included from undo.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from undo.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff alloc.c
In file included from alloc.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from alloc.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff data.c
In file included from data.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from data.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff doc.c
In file included from doc.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from doc.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff editfns.c
In file included from editfns.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from editfns.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff callint.c
In file included from callint.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from callint.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff eval.c
In file included from eval.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from eval.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff floatfns.c
In file included from floatfns.c:47:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from floatfns.c:47:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff fns.c
In file included from fns.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from fns.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff print.c
In file included from print.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from print.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff lread.c
In file included from lread.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from lread.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff abbrev.c
In file included from abbrev.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from abbrev.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff syntax.c
In file included from syntax.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from syntax.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff unexec.c
In file included from unexec.c:168:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from unexec.c:168:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff bytecode.c
In file included from bytecode.c:37:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from bytecode.c:37:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff process.c
In file included from process.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from process.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff callproc.c
In file included from callproc.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from callproc.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff region-cache.c
In file included from region-cache.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from region-cache.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff sound.c
In file included from sound.c:39:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from sound.c:39:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff atimer.c
In file included from atimer.c:21:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from atimer.c:21:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff doprnt.c
In file included from doprnt.c:24:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from doprnt.c:24:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff strftime.c
In file included from strftime.c:25:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from strftime.c:25:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff intervals.c
In file included from intervals.c:42:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from intervals.c:42:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff textprop.c
In file included from textprop.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from textprop.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff composite.c
In file included from composite.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from composite.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff md5.c
In file included from md5.c:24:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from md5.c:24:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff dosfns.c
In file included from dosfns.c:23:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from dosfns.c:23:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff msdos.c
In file included from msdos.c:27:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from msdos.c:27:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff w16select.c
In file included from w16select.c:31:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from w16select.c:31:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff termcap.c
In file included from termcap.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from termcap.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff tparam.c
In file included from tparam.c:21:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from tparam.c:21:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff lastfile.c
In file included from lastfile.c:39:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from lastfile.c:39:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff gmalloc.c
In file included from gmalloc.c:36:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from gmalloc.c:36:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff ralloc.c
In file included from ralloc.c:29:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from ralloc.c:29:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff vm-limit.c
In file included from vm-limit.c:22:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from vm-limit.c:22:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -c  -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff getloadavg.c
In file included from getloadavg.c:84:
config.h:1121:1: warning: "bzero" redefined
In file included from config.h:1055,
                 from getloadavg.c:84:
d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
gcc -Demacs -DHAVE_CONFIG_H   -I. -I.        -O2 -gcoff  ./prefix-args.c -o prefix-args
gcc        -o temacs  dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o 	charset.o coding.o category.o ccl.o 	cm.o term.o xfaces.o  	emacs.o keyboard.o macros.o keymap.o sysdep.o 	buffer.o filelock.o insdel.o marker.o 	minibuf.o fileio.o dired.o filemode.o 	cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o 	alloc.o data.o doc.o editfns.o callint.o 	eval.o floatfns.o fns.o print.o lread.o 	abbrev.o syntax.o unexec.o bytecode.o 	process.o callproc.o 	region-cache.o sound.o atimer.o 	doprnt.o strftime.o intervals.o textprop.o composite.o md5.o 	dosfns.o msdos.o w16select.o   termcap.o tparam.o lastfile.o gmalloc.o ralloc.o vm-limit.o   getloadavg.o                    -lg   -lm     
d:/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 0x11102 > 0xffff
rm -f ../etc/DOC
../lib-src/make-docfile -o ../etc/DOC -d . sunfns.o dosfns.o msdos.o   xterm.o xfns.o xmenu.o xselect.o xrdb.o   mac.o macterm.o macfns.o macmenu.o fontset.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o 	charset.o coding.o category.o ccl.o 	cm.o term.o xfaces.o  	emacs.o keyboard.o macros.o keymap.o sysdep.o 	buffer.o filelock.o insdel.o marker.o 	minibuf.o fileio.o dired.o filemode.o 	cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o 	alloc.o data.o doc.o editfns.o callint.o 	eval.o floatfns.o fns.o print.o lread.o 	abbrev.o syntax.o unexec.o bytecode.o 	process.o callproc.o 	region-cache.o sound.o atimer.o 	doprnt.o strftime.o intervals.o textprop.o composite.o md5.o 	dosfns.o msdos.o w16select.o   
../lib-src/make-docfile -a ../etc/DOC -d . ../lisp/mouse.elc   ../lisp/select.elc ../lisp/scroll-bar.elc   ../lisp/vmsproc.elc ../lisp/vms-patch.elc   ../lisp/ls-lisp.elc ../lisp/dos-fns.elc   ../lisp/w32-fns.elc ../lisp/dos-w32.elc   ../lisp/disp-table.elc ../lisp/dos-vars.elc   ../lisp/international/ccl.elc   ../lisp/international/codepage.elc ../lisp/abbrev.elc 	../lisp/buff-menu.elc 	../lisp/button.elc 	../lisp/emacs-lisp/byte-run.elc 	../lisp/cus-face.elc 	../lisp/cus-start.elc 	../lisp/custom.elc 	../lisp/emacs-lisp/backquote.elc 	../lisp/emacs-lisp/lisp-mode.elc 	../lisp/emacs-lisp/lisp.elc 	../lisp/facemenu.elc 	../lisp/faces.elc 	../lisp/files.elc 	../lisp/emacs-lisp/float-sup.elc 	../lisp/format.elc 	../lisp/frame.elc 	../lisp/help.elc 	../lisp/indent.elc 	../lisp/isearch.elc 	../lisp/loadup.el 	../lisp/loaddefs.el 	../lisp/bindings.elc 	../lisp/emacs-lisp/map-ynp.elc 	../lisp/env.elc 	../lisp/international/mule.elc 	../lisp/international/mule-conf.el 	../lisp/international/mule-cmds.elc 	../lisp/international/characters.elc 	../lisp/international/ucs-tables.elc 	../lisp/international/utf-8.elc 	../lisp/international/utf-16.elc 	../lisp/international/latin-1.el 	../lisp/international/latin-2.el 	../lisp/international/latin-3.el 	../lisp/international/latin-4.el 	../lisp/international/latin-5.el 	../lisp/international/latin-8.el 	../lisp/international/latin-9.el 	../lisp/case-table.elc 	../lisp/language/chinese.elc 	../lisp/language/cyrillic.elc 	../lisp/language/indian.elc 	../lisp/language/devanagari.el 	../lisp/language/kannada.el 	../lisp/language/malayalam.el 	../lisp/language/tamil.el 	../lisp/language/english.el 	../lisp/language/ethiopic.elc 	../lisp/language/european.elc 	../lisp/language/czech.el 	../lisp/language/slovak.el 	../lisp/language/romanian.el 	../lisp/language/greek.el 	../lisp/language/hebrew.el 	../lisp/language/japanese.el 	../lisp/language/korean.el 	../lisp/language/lao.el 	../lisp/language/thai.el 	../lisp/language/tibetan.elc 	../lisp/language/vietnamese.elc 	../lisp/language/misc-lang.el 	../lisp/language/utf-8-lang.el 	../lisp/language/georgian.el 	../lisp/menu-bar.elc 	../lisp/paths.el 	../lisp/register.elc 	../lisp/replace.elc 	../lisp/simple.elc 	../lisp/startup.elc 	../lisp/subr.elc 	../lisp/term/tty-colors.elc 	../lisp/font-core.elc 	../lisp/textmodes/fill.elc 	../lisp/textmodes/page.elc 	../lisp/textmodes/paragraphs.elc 	../lisp/textmodes/text-mode.elc 	../lisp/emacs-lisp/timer.elc 	../lisp/vc-hooks.elc 	../lisp/ediff-hook.elc 	../lisp/widget.elc 	../lisp/window.elc 	../lisp/version.el
stubedit temacs.exe minstack=100k
set LC_ALL=C; ./temacs -batch -l loadup dump
Loading loadup.el (source)...
Using load-path (../lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version.el (source)...
Loading widget...
Loading custom...
Loading emacs-lisp/map-ynp...
Loading env...
Loading cus-start...
Loading international/mule...
Exiting due to signal SIGABRT
Raised at eip=00122e0e
eax=002b1ddc ebx=00000120 ecx=00000000 edx=00000000 esi=002c0001 edi=001368c0
ebp=002b1e88 esp=002b1dd8 program=D:\src\emacs\src\temacs.exe
cs: sel=02a7  base=02c90000  limit=0035ffff
ds: sel=02af  base=02c90000  limit=0035ffff
es: sel=02af  base=02c90000  limit=0035ffff
fs: sel=027f  base=0001c620  limit=0000ffff
gs: sel=02cf  base=00000000  limit=0010ffff
ss: sel=02af  base=02c90000  limit=0035ffff
App stack: [002b2878..00299878]  Exceptn stack: [0029974c..0029780c]

Call frame traceback EIPs:
  0x00122d34 ___djgpp_traceback_exit+48
  0x00122e0e _raise+90
  0x0010e28d _abort+45, line 0 of msdos.c
  0x000b2459 _mark_object+1801, line 5116 of alloc.c
  0x000b218f _mark_object+1087, line 4973 of alloc.c
  0x000b1b58 _Fgarbage_collect+1400, line 4457 of alloc.c
  0x000c8519 _Feval+1241, line 2011 of eval.c
  0x000deb09 _readevalloop+441, line 1378 of lread.c
  0x000dd982 _Fload+1266, line 915 of lread.c
  0x000c83f6 _Feval+950, line 2126 of eval.c
  0x000deb09 _readevalloop+441, line 1378 of lread.c
  0x000dd982 _Fload+1266, line 915 of lread.c
  0x000c83f6 _Feval+950, line 2126 of eval.c
  0x000614f2 _top_level_2+18, line 1319 of keyboard.c
  0x000c70bd _internal_condition_case+221, line 1368 of eval.c
  0x000615b1 _top_level_1+49, line 1331 of keyboard.c
  0x000c6bda _internal_catch+186, line 1128 of eval.c
  0x00061458 _command_loop+88, line 1287 of keyboard.c
  0x00060f4d _recursive_edit_1+109, line 982 of keyboard.c
  0x00061085 _Frecursive_edit+133, line 1043 of keyboard.c
  0x0005f3ce _main+1838, line 1739 of emacs.c
  0x00119bf8 ___crt1_startup+176
make.exe[1]: *** [emacs] Error -1
make.exe[1]: Leaving directory `d:/src/emacs/src'
make.exe: *** [src] Error 2

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-07 23:47   ` Jan D.
@ 2004-11-08  8:10     ` Eli Zaretskii
  2004-11-08 12:56       ` Eli Zaretskii
                         ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-08  8:10 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Mon, 08 Nov 2004 00:47:47 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org
> 
> I checked out a fresh CVS as of 7 November, 23:50.  The lisp files has 
> been compiled on GNU/Linux, with make recompile in lisp and then make 
> distclean.  The tree was then copied to a dos disk on the same machine 
> and MS Windows was booted.

That two-step GNU/Linux-Windows dance wasn't necessary, strictly
speaking, since bootstrapping works in the DJGPP build (or at least it
did when I last tried it, which, admittedly, was a while ago).

But that is not really relevant to your problem.

> I've attached two files, one with "config 
> msdos" output, and one with make output (I did not do any commands in 
> between).  The make.txt file has been symified.  Comparing these to the 
> ones with USE_LSB_TAG undef:ed shows one difference that might be 
> relevant.  Not that I know what it means :-), but it occurs when temacs 
> is linked.
> 
> d:/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 0x11102 > 0xffff

This warning is harmless.  It is printed by ld because Emacs is
compiled with COFF debug info (the -gcoff option to GCC; I never got
to making unexec work for DJGPP with the DWARF-2 debug info), and COFF
debug info cannot have more than 64K source-line records, the
structures that tell the debugger what is the address of each source
line in the binary.

Are you saying that building with USE_LSB_TAG undefined does not
produce this warning?  That would be extremely strange, as I don't
think the build without USE_LSB_TAG can reduce the number of source
lines by 1103 hex (=4355 decimal) lines, which is the difference
between 0x11102 and 0xffff.

> The OS is MS Windows XP, service pack 1.

This is one difference between us: I never tried to build on an XP
machine; mine runs Windows 98.  Please be sure to download and install
the latest version of djdev203.zip from this site:

   ftp://ftp.delorie.com/pub/djgpp/current/v2/djdev203.zip

The other difference is the newer Binutils version you use, although
you say that older versions caused the same trouble.

> D:\src\emacs>config msdos
> Checking whether 'sed' is available...
> Checking whether 'rm' is available...
> Checking whether 'mv' is available...
> Checking whether 'gcc' is available...
> Checking what version of DJGPP is installed...
> Checking whether 'djecho' is available...
> Configuring for DJGPP Version 2 ...
> Configuring the source directory...
> Configuring the library source directory...
> Configuring the manual directory...
> Configuring the ELisp manual directory...
> Configuring the ELisp Introduction manual directory...
> Configuring the lisp directory...
> Configuring the leim directory...
> Configuring the main directory...
> Looking for the GDB init file...
> File `src/_gdbinit' created
> Looking for the GDB init file...found

This is fine.

> In file included from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
> ../src/config.h:1121:1: warning: "bzero" redefined
> In file included from ../src/config.h:1055,
>                  from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
> d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition

This is an annoyance (I fixed it locally for me a long time ago, but
now I see my fix is not good for others).  I will fix that now in a
better way in the Emacs CVS; stay tuned.  Again, I don't think it's
relevant to your problem, but perhaps it could explain why I don't see
the bug.  Hmm...

> Loading international/mule...
> Exiting due to signal SIGABRT
> Raised at eip=00122e0e
> eax=002b1ddc ebx=00000120 ecx=00000000 edx=00000000 esi=002c0001 edi=001368c0
> ebp=002b1e88 esp=002b1dd8 program=D:\src\emacs\src\temacs.exe
> cs: sel=02a7  base=02c90000  limit=0035ffff
> ds: sel=02af  base=02c90000  limit=0035ffff
> es: sel=02af  base=02c90000  limit=0035ffff
> fs: sel=027f  base=0001c620  limit=0000ffff
> gs: sel=02cf  base=00000000  limit=0010ffff
> ss: sel=02af  base=02c90000  limit=0035ffff
> App stack: [002b2878..00299878]  Exceptn stack: [0029974c..0029780c]
> 
> Call frame traceback EIPs:
>   0x00122d34 ___djgpp_traceback_exit+48
>   0x00122e0e _raise+90
>   0x0010e28d _abort+45, line 0 of msdos.c
>   0x000b2459 _mark_object+1801, line 5116 of alloc.c
>   0x000b218f _mark_object+1087, line 4973 of alloc.c
>   0x000b1b58 _Fgarbage_collect+1400, line 4457 of alloc.c

Hmm.. sounds like a real bug, which somehow doesn't happen for me.  I
will try several things to reproduce it, but in the meanwhile, please
try to debug the crash using the guidelines in etc/DEBUG (under
"Debugging problems which happen in GC"), as from the debug session
you posted earlier it looked like a real integer crept into a Lisp
object, i.e. somewhere we don't call make_number or something.  Please
try to find out what Lisp data structure is being marked at the point
of the crash; when we know that, a simple search through sources
should pinpoint the offender.

Note that hardware-assisted breakpoints and watchpoints don't work on
XP in the DJGPP port of GDB (due to a bug in the XP implementation of
the DPMI spec), so don't try to use hbreak and watch commands.  (What
version of GDB do you have installed, btw?)

Last, but not least, thanks for working on this.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-08  8:10     ` Eli Zaretskii
@ 2004-11-08 12:56       ` Eli Zaretskii
  2004-11-08 16:44       ` Eli Zaretskii
  2004-11-08 20:40       ` Jan D.
  2 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-08 12:56 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Mon, 08 Nov 2004 10:10:43 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > In file included from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
> > ../src/config.h:1121:1: warning: "bzero" redefined
> > In file included from ../src/config.h:1055,
> >                  from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
> > d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
> 
> This is an annoyance (I fixed it locally for me a long time ago, but
> now I see my fix is not good for others).  I will fix that now in a
> better way in the Emacs CVS; stay tuned.

This annoyance should be fixed now; please try again.

I'm still unable to reproduce your crash, though.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-07 10:13 DJGPP only dumps with USE_LISP_UNION_TYPE ?? Jan D.
  2004-11-07 10:50 ` Andreas Schwab
  2004-11-07 21:56 ` Eli Zaretskii
@ 2004-11-08 15:15 ` Stefan
  2 siblings, 0 replies; 28+ messages in thread
From: Stefan @ 2004-11-08 15:15 UTC (permalink / raw)
  Cc: emacs devel

> I was trying to get Emacs to compile on djgpp 2.03.  But it crashed every
> time in the dump phase, at the first GC.  I tried different gcc versions
> (2.95, 3.22, 3.42), different binutils versions (2.11, 2.15), with and
> without optimizations, with and without debugging but it always crashed at
> the same spot.  Since it crashed in GC, I tried to set the
> USE_LISP_UNION_TYPE (found a couple of errors and checked them in), and to
> my surprise, I got a working Emacs.

To debug problems related to USE_LSB_TAG, the first thing to do is to
use -DENABLE_CHECKING.  Of course it doesn't always help,


        Stefan

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-08  8:10     ` Eli Zaretskii
  2004-11-08 12:56       ` Eli Zaretskii
@ 2004-11-08 16:44       ` Eli Zaretskii
  2004-11-08 20:40       ` Jan D.
  2 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-08 16:44 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Mon, 08 Nov 2004 10:10:43 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Hmm.. sounds like a real bug, which somehow doesn't happen for me.  I
> will try several things to reproduce it

Sorry, no matter what I tried, I couldn't crash it.

So please do try to see what Lisp symbols and data structures are
being marked near the point of the crash, using the last_marked[]
array as your guide.

TIA

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-08  8:10     ` Eli Zaretskii
  2004-11-08 12:56       ` Eli Zaretskii
  2004-11-08 16:44       ` Eli Zaretskii
@ 2004-11-08 20:40       ` Jan D.
  2004-11-09  5:01         ` Eli Zaretskii
  2 siblings, 1 reply; 28+ messages in thread
From: Jan D. @ 2004-11-08 20:40 UTC (permalink / raw)
  Cc: monnier, emacs-devel

Eli Zaretskii wrote:

>>
>>d:/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 0x11102 > 0xffff
> 
> 
> This warning is harmless.  It is printed by ld because Emacs is
> compiled with COFF debug info (the -gcoff option to GCC; I never got
> to making unexec work for DJGPP with the DWARF-2 debug info), and COFF
> debug info cannot have more than 64K source-line records, the
> structures that tell the debugger what is the address of each source
> line in the binary.
> 
> Are you saying that building with USE_LSB_TAG undefined does not
> produce this warning?  That would be extremely strange, as I don't
> think the build without USE_LSB_TAG can reduce the number of source
> lines by 1103 hex (=4355 decimal) lines, which is the difference
> between 0x11102 and 0xffff.

Yes, this is the case.

> 
> 
>>The OS is MS Windows XP, service pack 1.
> 
> 
> This is one difference between us: I never tried to build on an XP
> machine; mine runs Windows 98.  Please be sure to download and install
> the latest version of djdev203.zip from this site:
> 
>    ftp://ftp.delorie.com/pub/djgpp/current/v2/djdev203.zip

That was the version I have (did a cmp).


>>In file included from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
>>../src/config.h:1121:1: warning: "bzero" redefined
>>In file included from ../src/config.h:1055,
>>                 from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24:
>>d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition
> 
> 
> This is an annoyance (I fixed it locally for me a long time ago, but
> now I see my fix is not good for others).  I will fix that now in a
> better way in the Emacs CVS; stay tuned.  Again, I don't think it's
> relevant to your problem, but perhaps it could explain why I don't see
> the bug.  Hmm...

This annoyance is gone now, thanks.

> Hmm.. sounds like a real bug, which somehow doesn't happen for me.  I
> will try several things to reproduce it, but in the meanwhile, please
> try to debug the crash using the guidelines in etc/DEBUG (under
> "Debugging problems which happen in GC"), as from the debug session
> you posted earlier it looked like a real integer crept into a Lisp
> object, i.e. somewhere we don't call make_number or something.  Please
> try to find out what Lisp data structure is being marked at the point
> of the crash; when we know that, a simple search through sources
> should pinpoint the offender.
> 
> Note that hardware-assisted breakpoints and watchpoints don't work on
> XP in the DJGPP port of GDB (due to a bug in the XP implementation of
> the DPMI spec), so don't try to use hbreak and watch commands.  (What
> version of GDB do you have installed, btw?)

GDB 6.1.1.

The variable it craches on is Vbuffer_local_symbols (I found out that 
earlier).  I don't think a real integer was inserted, but the data has 
been corrupted.  For example. the array size of Vbuffer_local_symbols is 
3305473.  I don't think that is reasonable.  last_marked didn't give any 
useful information.  I looked at the 70 last marked objects, there where 
mainly zeros, with a couple of Qt and Qnil here and there.

Stefan wrote:

> To debug problems related to USE_LSB_TAG, the first thing to do is to
> use -DENABLE_CHECKING.  Of course it doesn't always help,


It does in this case:

Emacs fatal error: buffer.c:4944: assertion failed: XTYPE 
(&buffer_defaults) == 0

In gdb I see that &buffer_local_symbols which is what 
Vbuffer_local_symbols uses, isn't aligned to an even 8 either.  These 
are aligned to an even 4.  So DECL_ALIGN isn't working in this 
configuration (?).  Sounds strange.


	Jan D.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-08 20:40       ` Jan D.
@ 2004-11-09  5:01         ` Eli Zaretskii
  2004-11-09 10:25           ` Jan D.
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-09  5:01 UTC (permalink / raw)
  Cc: monnier, emacs-devel

> Date: Mon, 08 Nov 2004 21:40:35 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org, monnier@iro.umontreal.ca
> 
> >>d:/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 0x11102 > 0xffff
> > 
> > 
> > This warning is harmless.  It is printed by ld because Emacs is
> > compiled with COFF debug info (the -gcoff option to GCC; I never got
> > to making unexec work for DJGPP with the DWARF-2 debug info), and COFF
> > debug info cannot have more than 64K source-line records, the
> > structures that tell the debugger what is the address of each source
> > line in the binary.
> > 
> > Are you saying that building with USE_LSB_TAG undefined does not
> > produce this warning?  That would be extremely strange, as I don't
> > think the build without USE_LSB_TAG can reduce the number of source
> > lines by 1103 hex (=4355 decimal) lines, which is the difference
> > between 0x11102 and 0xffff.
> 
> Yes, this is the case.

Interesting.  Curiously enough, my builds (on Windows 98) cite a much
larger number:

  d:/usr/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 0x1128a > 0xffff

> Emacs fatal error: buffer.c:4944: assertion failed: XTYPE 
> (&buffer_defaults) == 0
> 
> In gdb I see that &buffer_local_symbols which is what 
> Vbuffer_local_symbols uses, isn't aligned to an even 8 either.  These 
> are aligned to an even 4.  So DECL_ALIGN isn't working in this 
> configuration (?).  Sounds strange.

Could you write a short test program that demonstrates whether
DECL_ALIGN works, and see if it fails on XP?  (I could run it on my
machine to see if it works on 98, which I think it does.)  If
DECL_ALIGN doesn't work, we certainly cannot use LSB tags in the XP
build.  We could then make the test program part of config.bat to DTRT
at build time.

Please also upgrade to a newer GCC version (I use 3.3.3), in case
there's some alignment bug in your version.

TIA

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-09  5:01         ` Eli Zaretskii
@ 2004-11-09 10:25           ` Jan D.
  2004-11-09 14:17             ` Stefan
                               ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Jan D. @ 2004-11-09 10:25 UTC (permalink / raw)
  Cc: monnier, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

Eli Zaretskii wrote:

>>Emacs fatal error: buffer.c:4944: assertion failed: XTYPE 
>>(&buffer_defaults) == 0
>>
>>In gdb I see that &buffer_local_symbols which is what 
>>Vbuffer_local_symbols uses, isn't aligned to an even 8 either.  These 
>>are aligned to an even 4.  So DECL_ALIGN isn't working in this 
>>configuration (?).  Sounds strange.
> 
> 
> Could you write a short test program that demonstrates whether
> DECL_ALIGN works, and see if it fails on XP?  (I could run it on my
> machine to see if it works on 98, which I think it does.)  If
> DECL_ALIGN doesn't work, we certainly cannot use LSB tags in the XP
> build.  We could then make the test program part of config.bat to DTRT
> at build time.
> 
> Please also upgrade to a newer GCC version (I use 3.3.3), in case
> there's some alignment bug in your version.

Test program attached.  Output when compiling in Cygwin, Gnu/Linux or MacOSX 
is as expected:

ss1: rem 0
ss2: rem 0
ss3: rem 0
ss4: rem 0

but for djgpp (didn't find gcc 3.3.3, but 3.3.4):

D:\src>gcc -v
Reading specs from d:/djgpp/bin/../lib/gcc-lib/djgpp/3.34/specs
Configured with: /gcc/gnu/gcc-3.34/configure djgpp --prefix=/dev/env/DJDIR --dis
able-nls
Thread model: single
gcc version 3.3.4

D:\src>make align
gcc     align.c   -o align

D:\src>align
ss1: rem 4
ss2: rem 4
ss3: rem 4
ss4: rem 4

Very strange, considering Gnu/Linux and Cygwin are on the same machine.

	Jan D.


[-- Attachment #2: align.c --]
[-- Type: text/plain, Size: 600 bytes --]

#include <stdio.h>

#define GCTYPEBITS 3
#  define DECL_ALIGN(type, var) \
    type __attribute__ ((__aligned__ (1 << GCTYPEBITS))) var

struct SS
{
  char *ptr;
  long nr;
};


DECL_ALIGN (struct SS, ss1);
DECL_ALIGN (struct SS, ss2);
DECL_ALIGN (struct SS, ss3);
DECL_ALIGN (struct SS, ss4);

int
main ()
{
  int rem;

  rem = (unsigned long)&ss1 % 8;
  printf ("ss1: rem %d\n", rem);
  rem = (unsigned long)&ss2 % 8;
  printf ("ss2: rem %d\n", rem);
  rem = (unsigned long)&ss3 % 8;
  printf ("ss3: rem %d\n", rem);
  rem = (unsigned long)&ss4 % 8;
  printf ("ss4: rem %d\n", rem);

  return 0;
}

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-09 10:25           ` Jan D.
@ 2004-11-09 14:17             ` Stefan
  2004-11-09 17:28               ` Jan D.
  2004-11-10  4:36             ` Eli Zaretskii
  2004-11-11 20:03             ` Eli Zaretskii
  2 siblings, 1 reply; 28+ messages in thread
From: Stefan @ 2004-11-09 14:17 UTC (permalink / raw)
  Cc: Eli Zaretskii, emacs-devel

> but for djgpp (didn't find gcc 3.3.3, but 3.3.4):

> D:\src>gcc -v
> Reading specs from d:/djgpp/bin/../lib/gcc-lib/djgpp/3.34/specs
> Configured with: /gcc/gnu/gcc-3.34/configure djgpp --prefix=/dev/env/DJDIR --dis
> able-nls
> Thread model: single
> gcc version 3.3.4

> D:\src>make align
> gcc     align.c   -o align

> D:\src>align
> ss1: rem 4
> ss2: rem 4
> ss3: rem 4
> ss4: rem 4

This seems to indicate that DJGPP's `gcc' ignores the
__aligned__ annotation.  Could someone post something on some DJGPP
mailing-list to try and figure out what's really going on?

> Very strange, considering Gnu/Linux and Cygwin are on the same machine.

It should not be an OS and libc issue, only a compiler issue.
At least, AFAIK.


        Stefan

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-09 14:17             ` Stefan
@ 2004-11-09 17:28               ` Jan D.
  2004-11-10  4:42                 ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Jan D. @ 2004-11-09 17:28 UTC (permalink / raw)
  Cc: Eli Zaretskii, emacs-devel


>
> This seems to indicate that DJGPP's `gcc' ignores the
> __aligned__ annotation.  Could someone post something on some DJGPP
> mailing-list to try and figure out what's really going on?
>
>> Very strange, considering Gnu/Linux and Cygwin are on the same 
>> machine.
>
> It should not be an OS and libc issue, only a compiler issue.
> At least, AFAIK.

I checked the assembler output from gcc and it seems OK, the .comm 
directives for s1 to 4 are the same as for GNU/Linux.  So either the 
assembler or linker is doing something bad.  DJGPP also runs something 
called stubify after the linker, I don't know what it does, but it 
could also be responsible.

	Jan D.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-09 10:25           ` Jan D.
  2004-11-09 14:17             ` Stefan
@ 2004-11-10  4:36             ` Eli Zaretskii
  2004-11-12 18:23               ` Eli Zaretskii
  2004-11-11 20:03             ` Eli Zaretskii
  2 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-10  4:36 UTC (permalink / raw)
  Cc: monnier, emacs-devel

> Date: Tue, 09 Nov 2004 11:25:22 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> D:\src>align
> ss1: rem 4
> ss2: rem 4
> ss3: rem 4
> ss4: rem 4

The result on Windows 98 is like what you saw on GNU/Linux and Cygwin.
So, as I suspected, DECL_ALIGN fails on XP when compiled with DJGPP.

> Very strange, considering Gnu/Linux and Cygwin are on the same machine.

The OS is also involved here, since the alignment of the program
sections matters, and DPMI has its own ideas about that.

I will modify config.bat to do this test and build Emacs
appropriately.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-09 17:28               ` Jan D.
@ 2004-11-10  4:42                 ` Eli Zaretskii
  2004-11-10  8:12                   ` Jan D.
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-10  4:42 UTC (permalink / raw)
  Cc: monnier, emacs-devel

> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Tue, 9 Nov 2004 18:28:18 +0100
> 
> I checked the assembler output from gcc and it seems OK, the .comm 
> directives for s1 to 4 are the same as for GNU/Linux.

Of course!  __align__ works in DJGPP, I tested it when LSB tags were
introduced.

> So either the assembler or linker is doing something bad.

They don't: DECL_ALIGN works on platforms other than XP.

> DJGPP also runs something called stubify after the linker, I don't
> know what it does, but it could also be responsible.

It isn't.  stubify simply prepends a small 2KB stub to the otherwise
COFF executable, since DOS and Windows don't know how to run COFF
images.  The stub is a DOS program that, when invoked, loads the COFF
image into memory, switches the CPU into 32-bit protected mode, and
then passes control to the entry point of the COFF image.

So stubify.exe cannot possibly break alignment of the COFF code.

I will take this problem (later today) with the other DJGPP developers
on the DJGPP developers' list and see what I come up with.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-10  4:42                 ` Eli Zaretskii
@ 2004-11-10  8:12                   ` Jan D.
  2004-11-10 21:05                     ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Jan D. @ 2004-11-10  8:12 UTC (permalink / raw)
  Cc: monnier, emacs-devel

>> I checked the assembler output from gcc and it seems OK, the .comm
>> directives for s1 to 4 are the same as for GNU/Linux.
>
> Of course!  __align__ works in DJGPP, I tested it when LSB tags were
> introduced.
>
>> So either the assembler or linker is doing something bad.
>
> They don't: DECL_ALIGN works on platforms other than XP.

I was thinking that maybe they did some runtime test that resulted in 
different behaviour between 98 and XP.

>
>> DJGPP also runs something called stubify after the linker, I don't
>> know what it does, but it could also be responsible.
>
> It isn't.  stubify simply prepends a small 2KB stub to the otherwise
> COFF executable, since DOS and Windows don't know how to run COFF
> images.  The stub is a DOS program that, when invoked, loads the COFF
> image into memory, switches the CPU into 32-bit protected mode, and
> then passes control to the entry point of the COFF image.

> The OS is also involved here, since the alignment of the program
> sections matters, and DPMI has its own ideas about that.

Sounds like a comlicated setup, all I wanted to do was to make sure my 
modifications compiled for all ports of Emacs :-)  Well, I'm glad that 
you seem to have an idea about where the problem is.

	Jan D.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-10  8:12                   ` Jan D.
@ 2004-11-10 21:05                     ` Eli Zaretskii
  0 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-10 21:05 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 10 Nov 2004 09:12:30 +0100
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > The OS is also involved here, since the alignment of the program
> > sections matters, and DPMI has its own ideas about that.
> 
> Sounds like a comlicated setup

It's not easy to produce a single executable that works on plain DOS,
any version of Windows, and emulators such as DOSEmu from GNU/Linux.
DPMI, the DOS Protected Mode Interface, is the API used by the DJGPP
programs to run 32-bit protected-mode code on top of 16-bit OS, and
still be able to invoke 16-bit real-mode system calls without crashing
the OS.

Unfortunately, DPMI doesn't give any control of memory allocation
strategy or its alignment.

I asked the other DJGPP developers for ideas of why this happens on XP
and how to overcome it.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-09 10:25           ` Jan D.
  2004-11-09 14:17             ` Stefan
  2004-11-10  4:36             ` Eli Zaretskii
@ 2004-11-11 20:03             ` Eli Zaretskii
  2 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-11 20:03 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Tue, 09 Nov 2004 11:25:22 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> D:\src>gcc -v
> Reading specs from d:/djgpp/bin/../lib/gcc-lib/djgpp/3.34/specs
> Configured with: /gcc/gnu/gcc-3.34/configure djgpp --prefix=/dev/env/DJDIR --dis
> able-nls
> Thread model: single
> gcc version 3.3.4
> 
> D:\src>make align
> gcc     align.c   -o align
> 
> D:\src>align
> ss1: rem 4
> ss2: rem 4
> ss3: rem 4
> ss4: rem 4

Up until now, I tried the test program on 2 XP boxes and one Windows
2000 machine, and the program printed zeros on all 3 of them (as it
did on Windows 98 and on plain DOS).  I wonder why you see different
results.

How about if you send me the compiled binary (in private email,
please) as an attachment?

Also, I tried compiling the program with GCC 2.95.2 and got this
warning:

  align.c:14: warning: alignment of `ss1' is greater than maximum object file alignment. Using 4.

Didn't you see something like that when you tried to build Emacs with
GCC 2.9x?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-10  4:36             ` Eli Zaretskii
@ 2004-11-12 18:23               ` Eli Zaretskii
  2004-11-14 10:17                 ` Jan D.
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-12 18:23 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Wed, 10 Nov 2004 06:36:29 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> I will modify config.bat to do this test and build Emacs
> appropriately.

Done.  Could you please see if the new config.bat disables USE_LSB_TAG
automatically on your system?

If you see any problems, the place where I changed config.bat is near
the label "alignOk"; please see what is necessary to make it work for
you, and tell me how to fix it.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-12 18:23               ` Eli Zaretskii
@ 2004-11-14 10:17                 ` Jan D.
  2004-11-14 20:33                   ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Jan D. @ 2004-11-14 10:17 UTC (permalink / raw)
  Cc: emacs-devel

Eli Zaretskii wrote:
>>Date: Wed, 10 Nov 2004 06:36:29 +0200
>>From: "Eli Zaretskii" <eliz@gnu.org>
>>Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>>I will modify config.bat to do this test and build Emacs
>>appropriately.
> 
> 
> Done.  Could you please see if the new config.bat disables USE_LSB_TAG
> automatically on your system?
> 
> If you see any problems, the place where I changed config.bat is near
> the label "alignOk"; please see what is necessary to make it work for
> you, and tell me how to fix it.

The test fails, because echo/cmd.exe does not like &, it expects a command 
after it:

Configuring the source directory...
int main(void) { return (unsigned long)
'foo' is not recognized as an internal or external command,
operable program or batch file.
d:/djgpp/lib/crt0.o(.data+0xc2):crt0.s: undefined reference to `_main'
d:/djgpp/lib/libc.a(crt1.o)(.text+0x404):crt1.c: undefined reference to `_main'
collect2: ld returned 1 exit status
junk: No such file or directory (ENOENT)
'junk' is not recognized as an internal or external command,
operable program or batch file.

After reading some manuals, this makes it work (don't know if this is 
applicable to other DOS variants):

echo int main(void) { return (unsigned long)^&foo %% 8; }           >>junk.c

(i.e. a ^ before &).

But defining DECL_ALIGN in config.h does not disable USE_LSB_TAG.  The only 
way, sort of modifying lisp.h of course, is to define USE_LISP_UNION_TYPE instead.


	Jan D.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-14 10:17                 ` Jan D.
@ 2004-11-14 20:33                   ` Eli Zaretskii
  2004-11-27 12:36                     ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-14 20:33 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Sun, 14 Nov 2004 11:17:46 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org
> 
> After reading some manuals, this makes it work (don't know if this is 
> applicable to other DOS variants):
> 
> echo int main(void) { return (unsigned long)^&foo %% 8; }           >>junk.c
> 
> (i.e. a ^ before &).

I will see if this works with COMMAND.COM.

Alternatively, we could tell users to use "command /c config msdos",
but I dislike such solutions unless there's no better way.

> But defining DECL_ALIGN in config.h does not disable USE_LSB_TAG.

Ouch, you are right.

> The only 
> way, sort of modifying lisp.h of course, is to define USE_LISP_UNION_TYPE instead.

I don't want to force use of USE_LISP_UNION_TYPE.  I will add
something to disable LSB tags, that could be something other platforms
might need (we had a discussion in the past, and I think there was an
agreement that there should be a general way to disable LSB tags).

Thanks.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-14 20:33                   ` Eli Zaretskii
@ 2004-11-27 12:36                     ` Eli Zaretskii
  2004-11-27 16:31                       ` Jan D.
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-27 12:36 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Sun, 14 Nov 2004 22:33:01 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > But defining DECL_ALIGN in config.h does not disable USE_LSB_TAG.
> 
> Ouch, you are right.
> 
> > The only 
> > way, sort of modifying lisp.h of course, is to define USE_LISP_UNION_TYPE instead.
> 
> I don't want to force use of USE_LISP_UNION_TYPE.  I will add
> something to disable LSB tags

Done.  Please re-test.

TIA

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-27 12:36                     ` Eli Zaretskii
@ 2004-11-27 16:31                       ` Jan D.
  2004-11-27 16:33                         ` Eli Zaretskii
  2004-11-27 18:19                         ` Eli Zaretskii
  0 siblings, 2 replies; 28+ messages in thread
From: Jan D. @ 2004-11-27 16:31 UTC (permalink / raw)
  Cc: emacs-devel


>>> The only
>>> way, sort of modifying lisp.h of course, is to define 
>>> USE_LISP_UNION_TYPE instead.
>>
>> I don't want to force use of USE_LISP_UNION_TYPE.  I will add
>> something to disable LSB tags
>
> Done.  Please re-test.

It doesn't use LSB tags now, so the make for Emacs works.  But the 
alignment test is still wrong, the & is not escaped, so the echo fails 
as before:

Configuring the source directory...
int main(void) { return (unsigned long)
'foo' is not recognized as an internal or external command,
operable program or batch file.
d:/djgpp/lib/crt0.o(.data+0xc2):crt0.s: undefined reference to `_main'
d:/djgpp/lib/libc.a(crt1.o)(.text+0x404):crt1.c: undefined reference to 
`_main'
collect2: ld returned 1 exit status
junk: No such file or directory (ENOENT)
'junk' is not recognized as an internal or external command,
operable program or batch file.
WARNING: Your GCC does not support 8-byte aligned variables.
WARNING: Therefore Emacs cannot support buffers larger than 128MB.

	Jan D.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-27 16:31                       ` Jan D.
@ 2004-11-27 16:33                         ` Eli Zaretskii
  2004-11-27 18:19                         ` Eli Zaretskii
  1 sibling, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-27 16:33 UTC (permalink / raw)
  Cc: emacs-devel

> Cc: emacs-devel@gnu.org
> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sat, 27 Nov 2004 17:31:56 +0100
> 
> But the alignment test is still wrong, the & is not escaped, so the
> echo fails as before:

I forgot about the & nuisance.  Will fix that shortly.

Thanks.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-27 16:31                       ` Jan D.
  2004-11-27 16:33                         ` Eli Zaretskii
@ 2004-11-27 18:19                         ` Eli Zaretskii
  2004-11-27 22:54                           ` Jan D.
  1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2004-11-27 18:19 UTC (permalink / raw)
  Cc: emacs-devel

> Cc: emacs-devel@gnu.org
> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sat, 27 Nov 2004 17:31:56 +0100
> 
> But the alignment test is still wrong, the & is not escaped, so the
> echo fails as before:
> 
> Configuring the source directory...
> int main(void) { return (unsigned long)
> 'foo' is not recognized as an internal or external command,
> operable program or batch file.

Please try again, I hope it is now fixed.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
  2004-11-27 18:19                         ` Eli Zaretskii
@ 2004-11-27 22:54                           ` Jan D.
  0 siblings, 0 replies; 28+ messages in thread
From: Jan D. @ 2004-11-27 22:54 UTC (permalink / raw)
  Cc: emacs-devel


>> But the alignment test is still wrong, the & is not escaped, so the
>> echo fails as before:
>>
>> Configuring the source directory...
>> int main(void) { return (unsigned long)
>> 'foo' is not recognized as an internal or external command,
>> operable program or batch file.
>
> Please try again, I hope it is now fixed.

It works now.

	Jan D.

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2004-11-27 22:54 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-07 10:13 DJGPP only dumps with USE_LISP_UNION_TYPE ?? Jan D.
2004-11-07 10:50 ` Andreas Schwab
2004-11-07 12:02   ` Jan D.
2004-11-07 22:03     ` Eli Zaretskii
2004-11-07 21:56 ` Eli Zaretskii
2004-11-07 23:47   ` Jan D.
2004-11-08  8:10     ` Eli Zaretskii
2004-11-08 12:56       ` Eli Zaretskii
2004-11-08 16:44       ` Eli Zaretskii
2004-11-08 20:40       ` Jan D.
2004-11-09  5:01         ` Eli Zaretskii
2004-11-09 10:25           ` Jan D.
2004-11-09 14:17             ` Stefan
2004-11-09 17:28               ` Jan D.
2004-11-10  4:42                 ` Eli Zaretskii
2004-11-10  8:12                   ` Jan D.
2004-11-10 21:05                     ` Eli Zaretskii
2004-11-10  4:36             ` Eli Zaretskii
2004-11-12 18:23               ` Eli Zaretskii
2004-11-14 10:17                 ` Jan D.
2004-11-14 20:33                   ` Eli Zaretskii
2004-11-27 12:36                     ` Eli Zaretskii
2004-11-27 16:31                       ` Jan D.
2004-11-27 16:33                         ` Eli Zaretskii
2004-11-27 18:19                         ` Eli Zaretskii
2004-11-27 22:54                           ` Jan D.
2004-11-11 20:03             ` Eli Zaretskii
2004-11-08 15:15 ` Stefan

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).