Re: geomview

[slevy]

>From eps at Princeton.EDU Mon Jun  8 09:11:41 1992
>Date: Mon, 8 Jun 92 10:11:37 -0400
>From: Elisha Sacks <eps at Princeton.EDU>
>To: slevy at geom
>Subject: geomview
>
>Hi,
>
>We are having some trouble installing the new version.  Here is the message from
>the person who tried and failed.  Can you suggest anything?
>
>thanks,
>elisha.
>
> Under 4.0.4 on the R4000 (red), we're told by the build that:
> 
>         cc -I../../common -DRMAN -g -float -prototypes  -DMACHTYPE='"sgi"' -I../../../../../include -c motion.c
> accom: Error: motion.c, line 44: Prototypes inconsistent; Arg 4 mismatch:  int is different from: (no argument) 
>        { return objectdiagop(event, Scale, uistate.targetid); }
>        ----------------------------------------------------^

I'm having a hard time imagining what could cause this.  objectdiagop()
is prototyped to take 3 parameters, apparently called with 3 parameters here,
and later defined to take those same 3 params -- so what's this about
Arg 4 mismatch?  Could some include file define e.g. Scale to be a macro
including a comma?  None of ours do, under 4.0.1.

The only thing I can think to try would be to generate the preprocessor
output, e.g.
	cd gl/O.sgi
	make MORECOPTS=-E motion.o > motion.cpp

and look for "objectdiagop" in motion.cpp, which is what the compiler really
sees.  Mail it to me if you like.

> Under 3.x on an R3000 (oyoy), we're told (after the build successfully
> passes the problem above):
> 
>         cc -o trigrp -g -float -prototypes  -DMACHTYPE='"sgi"' -I../../../../include aargtrigrp.o trigrp.o  colormap.o group.o -L../../../../lib/sgi -L/usr/local/lib  -lpolylist -lbbox -linst -llist -ltlist  -lbbox -lgeom -lshade -lmg -lcamera -lwindow  -loogl -l3d -lcolor -lstub    -lgl_s -lm -lc_s
> /usr/bin/ld:
> Undefined:
> _us_rsthread_stdio

Ditto.  _us_rsthread_stdio should be in the regular C library: it's
mentioned in SGI's stdio.h getc() etc. macros.  I just looked on our
3.3.2 system; _us_rsthread_stdio is defined in mp_def.o inside
/usr/lib/libc.a.  It's hard to see how anything could compile on the
system without it, though -- why only trigrp?  Did e.g. geomview
compile and link correctly?

Could there be a libc.a in oyoy's /usr/local/lib which doesn't include the
standard SGI stuff?  Or, could something unpleasant have happened while
the package was compiling, e.g. a /tmp or /usr/tmp disk filling up?
Check /usr/adm/SYSLOG (or /usr/adm/oSYSLOG, cycled every Sunday) and look
for messages around the compile time -- or try compiling again.

    Stuart