compiling 1.1.3.7

compiling 1.1.3.7

[Channy Tremblay]

List,

I'm trying to compile the latests stuff.

I've seen the email 
"http://marc.theaimsgroup.com/?l=linux-msdos&m=103574450131849&w=2"

I'm getting a different error. Unfortunately I know almost nothing about 
lexer's or bison.

Here is the error:

make[2]: Entering directory `/home/channyt/dosemu-1.1.3/src/base/init'
bison -y -v -do parser.c  parser.y
parser.y:377.3: parse error, unexpected "|"

parser.y:377.26-68: $2 of `line' has no declared type
parser.y:378.20-63: $2 of `line' has no declared type
parser.y:378.20-74: $2 of `line' has no declared type
parser.y:379.19-64: $2 of `line' has no declared type
parser.y:379.19-75: $2 of `line' has no declared type
parser.y:380.36-393.19: $3 of `line' has no declared type
parser.y:402.51-403.21: $2 of `line' has no declared type
parser.y:402.51-403.25: invalid $ value
parser.y:402.51-403.25: $5 of `line' has no declared type
parser.y:405.78-406.21: $2 of `line' has no declared type
parser.y:405.78-406.43: $2 of `line' has no declared type
parser.y:405.78-406.46: $4 of `line' has no declared type
parser.y:405.78-406.49: invalid $ value
parser.y:405.78-406.49: $6 of `line' has no declared type

I didn't put everything, fixing the first error will probably fix the 
rst of it :)

channyt@munster:~/dosemu-1.1.3$ bison -V
bison (GNU Bison) 1.75

Any ideas?

Re: compiling 1.1.3.7

[Bart Oldeman]

On Thu, 21 Nov 2002, Channy Tremblay wrote:

> Here is the error:
>
> make[2]: Entering directory `/home/channyt/dosemu-1.1.3/src/base/init'
> bison -y -v -do parser.c  parser.y
> parser.y:377.3: parse error, unexpected "|"

Does it still err if you do
make distclean
and then recompile?

Bart

Re: compiling 1.1.3.7

[Bart Oldeman]

On Thu, 21 Nov 2002, Channy Tremblay wrote:

> channyt@munster:~/dosemu-1.1.3$ bison -V
> bison (GNU Bison) 1.75
>
> Any ideas?

Here's another idea: remove the semicolon on line 374 of
src/base/init/parser.y.

To really fix it (parser.y is generated using default-configure), you
must apply the patch below.

I have no idea why \n works and $ doesn't; maybe someone more familiar
with perl than myself does ...

Bart

--- dosemu-1.1.3.7/bisonpp.pl	Sun May 26 11:57:54 2002
+++ dosemu-1.1.3.8/bisonpp.pl	Thu Nov 21 21:42:35 2002
@@ -79,7 +79,7 @@
   $i = $$dir{$key};
   $$grammar[$i] =~ /^\S+?\s*:\s*(.*)/s;
   $rest = $1;
-  $rule =~ s/[ \t]*;\s*$//s;	# remove trailing ';'
+  $rule =~ s/[ \t]*;\s*\n//s;	# remove trailing ';'
   $rule =~ s/^(\S+?\s*:\s*)\|\s*/$1/s; # to be save: remove leading '|'
   $$grammar[$i] = "$rule\t\t| $rest";
 }

Re: compiling 1.1.3.7

[Ged Haywood]

Hi there,

On Thu, 21 Nov 2002, (or thereabouts) Bart Oldeman wrote:

> dosemu-1.1.3.7

Great stuff!

Thanks very much for the work you put in to get DOS extender stuff
going.  I can confirm that I can now run the extender versions of the
Norton (formerly Zortech, Zorland) C++ compiler, linker etc. and they
seem to sorta work, but I haven't done any serious testing yet.

Note:

This assembler doesn't seem to like src/commands/mgarrot.S:
GNU assembler version 2.11.2 (i586-pc-linux-gnu) using BFD version 2.11.2

This is OK:
GNU assembler version 2.9.1 (i386-slackware-linux), using BFD version 2.9.1.0.25

I haven't investigated further.

If you don't want to know about a small problem with the DOS-extender
version of the Norton C compiler stop reading now and press 'D'.

I can investigate further if you like but probably not until at least
February 2003.

73,
Ged.

----------------------------------------------------------------------

There is a small problem with the compiler which I can probably get
around but I wonder if it's of any interest to you to know about it.

Many years ago I wrote a system for invoicing, credit control, stock
control etc.  It still runs most of the finances for my business.

Being a paranoid programmer, I check that strings which are supposed
to be constant once loaded in RAM don't get whacked by wild pointers.
To check that they stay untouched I wrap each string in "guard" bytes
and I have some code which looks at the guard bytes to see if they are
changed.  If they are it's a sign of a serious program failure and the
whole system shuts down.  And of course I get a telephone call.

The text file containing the strings is read during the compilation
(via #include) and at run-time.  During compilation a list of pointers
(also constants) is generated, one per string, and this list is used
for the runtime wild pointer checking.  At present there are 826 text
strings in the file.

Now the funny thing is that the compiler compiles the source OK under
DOS but under DOSEMU it chokes with a DOS Stack fault:

C:\SOS\V4>make -fmaintx4.mak
ztcpp1x -C -DDOS386 -3 -ms -a2 -DLOTS_OF_FILES -otemp.tmp \sos\source\jmdebug

INTERRUPT 0CH, STACK FAULT
error code = 0000
eax = 00128028      esi = 00000000      flags = 0206        ds = 00E7
ebx = 0009D5D6      edi = 00127FF6      eip = 0000F780      es = 00E7
ecx = 00000000      ebp = 00036000      cs = 00DF           fs = 0000
edx = 00000010      esp = 00036000      ss = 00D7           gs = 0000
--- errorlevel 1

I found that if I remove some of the lines containing the strings
(i.e. truncate the file) I can get it to compile.  It is OK with 721
strings but no more.  It doesn't matter how long they are.  It doesn't
seem to matter which ones I remove.

This is all using MS-DOS 6.22 from the original distribution discs.
Linux 2.4.19 (compiled on the same machine).
Compilation options: static.  All others which default ON turned OFF
using setup-dosemu.
More info available, but only if you want it. :)
----------------------------------------------------------------------