🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.ghostscript.bug
Article #361

Compiler Errors in Ghostscript 2.5

#361
From: Del Lamb
Date: Thu, 10 Sep 1992 15:51
140 lines
7382 bytes
[]

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\   \\
============================================================================
Technical Details
Message-ID: <1992Sep10.155103.16084@sbcs.sunysb.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!sbcs.sunysb.edu!lambda

Show Full Headers
Complete Article Headers
Newsgroups: gnu.ghostscript.bug
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!sbcs.sunysb.edu!lambda
From: lambda@sbcs.sunysb.edu (Del Lamb)
Subject: Compiler Errors in Ghostscript 2.5
Message-ID: <1992Sep10.155103.16084@sbcs.sunysb.edu>
Sender: gnulists@ai.mit.edu
Organization: State University of New York at Stony Brook
Distribution: gnu
Date: Thu, 10 Sep 1992 15:51:03 GMT
Approved: bug-ghostscript@prep.ai.mit.edu
Lines: 141