From: lambda@sbcs.sunysb.edu (Del Lamb)
Newsgroups: gnu.ghostscript.bug
Subject: Compile Errors in Ghostscript 2.5
Date: 10 Sep 92 02:41:20 GMT
Distribution: gnu
Organization: State University of New York at Stony Brook

[]

Hello, I'm a newcomer to this group and Ghostscript, so forgive any
unintention violations of netiquette.  I'm trying to compile GS 2.5
on a i486 running System V, R4 V3 (Consensys V4, rel 1.3) and I have
a nasty (for me), but probably simple, compile problem.

In the compile for iinit.c, the following error messages occur:
[...]
        ./ccgs "cc  -O  -DSVR4" iinit.c
"iinit.c", line 159: left operand must be modifiable lvalue: op "="
"iinit.c", line 159: operand must be modifiable lvalue: op "++"
"iinit.c", line 175: left operand must be modifiable lvalue: op "="
"iinit.c", line 175: operand must be modifiable lvalue: op "++"
"iinit.c", line 186: left operand must be modifiable lvalue: op "="
"iinit.c", line 186: operand must be modifiable lvalue: op "++"
"iinit.c", line 201: left operand must be modifiable lvalue: op "="
mv: cannot access _temp_3084.o
[...]
        ./ccgs "cc  -O  -DSVR4" zprops.c
"zprops.c", line 177: left operand must be modifiable lvalue: op "+="
mv: cannot access _temp_3094.o
[...]
        ./echogs -n - cc  -L/usr/X386/lib -o gs gs.o ialloc.o idebug.o idict.o
 idparam.o  iinit.o iname.o  interp.o isave.o iscan.o iutil.o  sfilter.o strea
m.o  zarith.o zarray.o zcontrol.o zdict.o  zfile.o zfileio.o zfilter.o zgeneri
c.o  zmath.o zmisc.o zpacked.o zprops.o zrelbit.o  zstack.o zstring.o ztype.o 
zvmem.o  zchar.o zcolor.o zfont.o zfont1.o zfont2.o  zdevice.o zgstate.o zht.o
 zmatrix.o  zpaint.o zpath.o zpath2.o gsmain.o gschar.o gscolor.o gscoord.o  g
sdevice.o gsfile.o gsfont.o gsimage.o gsimage2.o  gsimpath.o gsline.o gsmatrix
.o gsmisc.o  gspaint.o gspath.o gspath2.o  gsstate.o gstdev.o gstype1.o gsutil
.o  gxcache.o gxclist.o gxcolor.o gxcpath.o  gxdither.o gxdraw.o gxfill.o gxhi
nt1.o gxht.o  gxpath.o gxpath2.o gxpcopy.o gxstroke.o  gdevmem1.o gdevmem2.o g
devmem3.o gconfig.o >_temp_
        ./echogs -x 205c >>_temp_
        cat obj.tr >>_temp_
        cat lib.tr >>_temp_
        echo  -lm >>_temp_
        /bin/sh <_temp_
ld: iinit.o: fatal error: cannot open file for reading
*** Error code 1 (bu21)

The code associated with each of this error message is as follows:
==From: iinit.c [153-202] errors:{159,175,186,201}===========================
153:/* Run the initialization procedures of the individual operator files. */
154:void
155:zop_init()
156:{       op_def_ptr _ds *tptr;
157:        op_def_ptr def;
158:        for ( tptr = op_defs_all; *tptr != 0; tptr++ )
159#           {    for ( def = *tptr; def->oname != 0; def++ ) ;
160:                if ( def->proc != 0 )
161:                        ((void (*)(P0()))(def->proc))();
162:           }
163:}
164:/* Initialize the operator table. */
165:void
166:op_init()
167:{       int count = 1;
168:        op_def_ptr _ds *tptr;
169:        op_def_ptr def;
170:        const char _ds *nstr;
171:
172:        /* Do a first pass just to count the operators. */
173:
174:        for ( tptr = op_defs_all; *tptr != 0; tptr ++ )
175#         for ( def = *tptr; def->oname != 0; count++, def++ )
176:          ;
177:
178:        /* Do a second pass to construct the operator table, */
179:        /* and enter the operators in systemdict. */
180:
181:        op_def_table = (op_def_ptr *)alloc(count, sizeof(op_def_ptr),
182:                                           "op_init(op_def_table)");
183:        op_def_count = count;
184:        count = 1;
185:        for ( tptr = op_defs_all; *tptr != 0; tptr ++ )
186#         for ( def = *tptr; (nstr = def->oname) != 0; count++, def++ )
187:           {    ref nref, oper;
188:                make_oper(&oper, count, (dummy_op_proc_p)(def->proc));
189:                interp_fix_op(&oper);          /* optimize if possible */
190:                /* The first character of the name is a digit */
191:                /* giving the minimum acceptable number of operands. */
192:                /* For now, we just skip over it. */
193:                nstr++;
194:                /* Don't enter internal operators into systemdict. */
195:                if ( *nstr == '%' )
196:                        name_enter(nstr, &nref);
197:                else
198:                        initial_enter_name(nstr, &oper);
199:                if ( def->oindex != 0 )
200:                        *def->oindex = count;
201#                op_def_table[count] = def;
202:           }

==From: zprops.c [167-183] errors:{177}=====================================
167:/* Set properties from the stack. */
168:/* Returns the number of elements copied. */
169:/* Entries with non-name keys are not copied; */
170:/* entries with invalid values are copied with status = pv_typecheck. */
171:private int
172:props_from_stack(gs_prop_item *plist /* [count + acount] */,
173:   const_os_ptr op0, int count)
174:{       gs_prop_item *pi = plist;
175:        gs_prop_item *pai = plist + count;
176:        const_os_ptr op = op0 + 1;
177#        for ( ; count; op += 2, count-- )
178:           {    ref sref;
179:                if ( !r_has_type(op - 1, t_name) ) return e_typecheck;
180:                name_string_ref(op - 1, &sref);
181:                pi->pname = (char *)sref.value.bytes;
182:                pi->name_size = r_size(&sref);
183:                pi->status = pv_set;
=============================================================================

The program was ported from "ftp.uu.net" on Sept 8th, and the only changes
I made were to the make file for the directory paths, the X11 include/lib
files (which are /usr/X386/* on this machine) and the device list, to which
I added "laserjet.dev ljet2p.dev ljetplus.dev epson.dev" because I wasn't
sure which would be best for a HP-Laserjet IIP+.  I now know from this
group that 'laserjet' is the one I want.  

I tend to think that the problem is not compiler error in nature, but some
value/flag/file that I haven't set right.  This is because I tried to use
Ghostscript 2.4.1 last night with exactly the same errors on exactly the
same lines.  Now, majors compiler errors in released code for a supported
system are unlikely.  I find it exceptionally unlikely that the same error
would still exist from 2.4.1 to 2.5.  So, can anybody shed some light as
to why this happens?  I will continue to study it, but I'm under some very
serious time constraints, so my ability to debug the code is limited.

Thanks in advance for any assistance.  Email if possible to reduce the
system bandwidth, though I will read this group.


   /\-|-/\            Del Lamb :  lambda@sbcs.sunysb.edu          /\+|+/\
  //\\|//\\                                                      //\\|//\\
 //__\X/  \\"Should we try using our intelligence?" - The Doctor//  \X/  \\
/----/A\   \\"Well... if you think that's a good idea." - Leela//   /X\   \\
============================================================================