Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!cfchiesa
From: cfchiesa@bsu-cs.bsu.edu (Christopher Chiesa)
Newsgroups: comp.sys.amiga
Subject: Re: Lattice LC question (Was "assign problem")
Keywords: looking for lc?'s in all the wrong places
Message-ID: <7719@bsu-cs.bsu.edu>
Date: 12 Jun 89 13:34:54 GMT
References: <7146@ecsvax.UUCP> <109395@sun.Eng.Sun.COM>
Organization: CS Dept, Ball St U, Muncie, IN, USA
Lines: 64


As long as we're talking about Lattice C and directory paths...

I spent about six hours yesterday trying to compile and link the "example"
programs that were part of the "PLplot" distribution recently on comp.binaries.
amiga.  This should have been totally trivial, as the distribution came with 
an Execute script that was supposed to do the compile-and-link FOR you!

Unfortunately, when I booted from my Workbench 1.2 disk (with Arp 1.2, if that
makes any difference?), inserted the Lattice disk and executed that disk's
startup-sequence to obtain the proper ASSIGNs, I ran into the problem of "LC"
not being findable because the Lattice_C disk wasn't in the drive; this was
with WB1.2 in one drive, and Plplot on its own disk in the other.  I then 
tried the obvious step of starting out with WB1.2 and Lattice_C in the drives;
this found LC but then didn't find the C source files.

I then said to hell with the Execute script and started typing things in by
hand.  That STILL didn't work right, as (the previous posting(s) suggest)
the right disks couldn't ALL be in the drive at the same time (three disks,
two floppy drives).  I tried booting the Lattice C disk instead, so that 
IT would be the "required" disk and always be requested when needed, which
worked okay as far as finding LC but crapped out when I tried to compile
to the RAM: device; perhaps the C disk has only WB 1.1 on it, and RAM: didn't
exist then?  Can anybody confirm?

To make a very long story very short, I ended up booting the WB disk again, 
then having to fully spell out all file pathnames: 

"Lattice_C:c/LC -oRAM:example01.o PLPLOT:examples/example01"    etc...

This successfully found "LC" and even "LC1" and "LC2," but blew up with a
"file not found" on each of "#include <stdio.h>" and "#include <math.h>" of
all things.  I added

      -iINCLUDE:lattice/

to the above command, and got a little further, and then the LINK step blew
up with about 20 "unresolved" references including a lot of _LVO stuff, of
which I specifically remember "_LVOClose".  

I looked up "Close()" in the RKM, and as far as I can tell it is in 
'intuition.h' (is this right?) which is NOT explicitly #include'd in the source
file; I guess next I'll have to iteratively edit the source files to add 
#include statements until, one by one, I can get rid of the errors.  

This sure seems like a helluva lot of work just to see some example programs,
especially since they're supposed to be "automatically" compilable.  

So how much of this is my own fault for not having a newer version of Lattice C,
how much for being totally ignorant of what I'm doing (and the manual doesn't
help much; it says NOTHING about how #include specifications are processed, for
instance; or is that part of "the C language," and therefore NOT appropriate 
to the COMPILER documentation?  Told'ja I was ignorant...), and how much due to
something I haven't even mentioned?

I've got a flock of other files sitting around waiting to be downloaded and
played with, so I'd love some help with this stuff.

Thanks in advance,

  Chris
-- 
UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa 
cfchiesa@bsu-cs.UUCP