kms@ecsvax.UUCP (Ken Steele) (06/11/89)
It seems that the Lattice LC is not maintaining the correct
directory path to lc1 and lc2. Here are the symptoms.
lc, lc1, lc2, blink are in L1: (no subdirectory). Libs and includes
are in L2: (in appropriate subdirectories). LC: is assigned to L1:,
INCLUDE: and LIB: are assigned to L2:, QUAD: is assigned to ram:,
and I added LC: to the search path. The source file is in sys:src.
SYS: is in DF0: and L1: is in DF1:. I then proceed to run the
ever-popular "lc -L sys:src/hello". After the sign-on garbage, I am
asked to insert L2: in ANY drive. If I put L2: in DF0:, then
compilation proceeds (with much-o disk swapping). If I put L2: in
DF1: (removing L1: of course) THEN I get the big screen-flash abort,
with the complaint that "LC2 is unknown command."
It seems as if LC is looking in currently mounted volumes for
LC2 instead of the logical device LC:. Has any else noted this?
If true, can LC be patched/zapped to look for lc:lc1 and
lc:lc2 _safely_?
Thanks for the help.
--ken
--
Ken Steele Dept. of Psychology kms@ecsvax.[bitnet || UUCP]
Mars Hill College kms@ecsvax.uncecs.edu
Mars Hill, NC 28754 cmcmanis%pepper@Sun.COM (Chuck McManis) (06/12/89)
In article <7146@ecsvax.UUCP> kms@ecsvax.UUCP (Ken Steele) writes: >It seems that the Lattice LC is not maintaining the correct >directory path to lc1 and lc2. Here are the symptoms. >lc, lc1, lc2, blink are in L1: (no subdirectory). Libs and includes >are in L2: (in appropriate subdirectories). LC: is assigned to L1:, >INCLUDE: and LIB: are assigned to L2:, QUAD: is assigned to ram:, >and I added LC: to the search path. The source file is in sys:src. This is a "feature" of the path command. When an unmounted volume is in the path, it is skipped rather than giving you lots of "insert volume XX:" messages. Sometimes that is desirable, other times it isn't. The solution to your problem is probably to make LC1 and LC2 resident. If you have the ram of course. If not, then you will need to put some stuff like LC2 in the mounted disk. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (06/12/89)
From article <7146@ecsvax.UUCP>, by kms@ecsvax.UUCP (Ken Steele): > > It seems that the Lattice LC is not maintaining the correct > directory path to lc1 and lc2. Here are the symptoms. > > lc, lc1, lc2, blink are in L1: (no subdirectory). Libs and includes > are in L2: (in appropriate subdirectories). LC: is assigned to L1:, > INCLUDE: and LIB: are assigned to L2:, QUAD: is assigned to ram:, LIB: should be assigned to L2:Lib and INCLUDE: should be assigned to L2:CompactH (assuming you're running version 5.0 or later). > and I added LC: to the search path. The source file is in sys:src. > SYS: is in DF0: and L1: is in DF1:. I then proceed to run the > ever-popular "lc -L sys:src/hello". After the sign-on garbage, I am > asked to insert L2: in ANY drive. If I put L2: in DF0:, then > compilation proceeds (with much-o disk swapping). If I put L2: in > DF1: (removing L1: of course) THEN I get the big screen-flash abort, > with the complaint that "LC2 is unknown command." This is a characteristic of the way "Path" works. If a directory in the search path is not mounted the command just skips it instead of asking you to insert the necessary disk. The "lc" command simply runs "lc1" followed by "lc2" (and followed by "Blink" if you specify "-L"). If "lc" were a single command you wouldn't have the problem because it would be loaded before you removed L1:. But when you replace L1: with L2: you remove the directory containing "lc2". Then "lc" tries to call "lc2". Although the directory where "lc2" resides would be searched if the disk were mounted, the "Path" command won't advise you to insert the disk. It just skips the missing directories and comes back with an "unknown command" message. > > It seems as if LC is looking in currently mounted volumes for > LC2 instead of the logical device LC:. Has any else noted this? > > If true, can LC be patched/zapped to look for lc:lc1 and > lc:lc2 _safely_? In a word, no. It would be an easy fix for Lattice, though, since they have the source code. > > Thanks for the help. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3
shadow@pawl.rpi.edu (Deven T. Corzine) (06/12/89)
In article <109395@sun.Eng.Sun.COM> cmcmanis%pepper@Sun.COM (Chuck McManis) writes: >This is a "feature" of the path command. When an unmounted volume is >in the path, it is skipped rather than giving you lots of "insert >volume XX:" messages. Sometimes that is desirable, other times it >isn't. The solution to your problem is probably to make LC1 and LC2 >resident. If you have the ram of course. If not, then you will need >to put some stuff like LC2 in the mounted disk. True, but LC should compensate by trying "lc:lc2" if the path fails for "lc2"... *sigh* Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
cfchiesa@bsu-cs.bsu.edu (Christopher Chiesa) (06/12/89)
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 cmcmanis%pepper@Sun.COM (Chuck McManis) (06/13/89)
In article <674@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >> If true, can LC be patched/zapped to look for lc:lc1 and >> lc:lc2 _safely_? > > In a word, no. It would be an easy fix for Lattice, though, since > they have the source code. Actually, you can compile and run the 'cc' front end that was posted here recently to allow you do this. All it needs do is execute lc1:lc1 and lc1:lc2 and it will work fine. I believe it was posted to comp.sources.amiga no too far back. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
morris-ng@cup.portal.com (Yuklung Morris Ng) (06/13/89)
I still can't figure out what is your assign are, but here is my startup with no problem at all: Stack 16000 c:Echo "" c:echo " Lattice *e[0;33mAmigaDOS C Compiler*e[0m Version 5.0" c:echo " Copyright ) 1988 *e[33mLattice, Inc.*e[0m" c:echo "" Assign INCLUDE: SYS:Program/LC/include LC: SYS:Program/LC/c Assign LIB: SYS:Program/LC/Lib QUAD: RAM: Path ADD SYS:Program/LC/c The Assign command is an ARP command, if you don't have it (well, you better do!) you can't onlt assign one device by using one command. Happy programming! +---------+----------------------------+----------------------------------+ | ///| Morris Y. L. Ng | Usenet: morris-ng@cup.portal.com | | /// | Computer Science & Finance | Portal: Yuklung Morris Ng | | /// | San Jose State University | Home : (###)###-#### (Guess?!) | |\\\/// +----------------------------+----------------------------------+ | \XX/ | "Be my Amiga! And I will be your Amigo!" | +---------+---------------------------------------------------------------+
kms@ecsvax.UUCP (Ken Steele) (06/13/89)
In article <7719@bsu-cs.bsu.edu>, cfchiesa@bsu-cs.bsu.edu (Christopher Chiesa) writes: > > 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! > > > 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 > What version of lattice are you using? In any case I can tell you that the examples in PLOTLIB do compile according to the execute script under Lattice 5.02. I made a slight change in organization. Maybe this will help you. I copied plotlib.lib into the directory where my other libs were. The example directory was copied onto my system disk, and I started the compile from there (with lc, lc1, lc2, blink in df1:). All libs are on a second disk, which blink asks for by its logical name LIB:. Note that you need to change the script file to reflect the new location of plotlib.lib (i.e., LIB:plotlib.lib) and, the way the script is written, lc (lc1,lc2,includes) must be in a currently mounted disk (thanks to all for that previous bit of advice). Also, beware that each output file is about 150k in size! > Chris Good Luck --ken -- Ken Steele Dept. of Psychology kms@ecsvax.[bitnet || UUCP] Mars Hill College kms@ecsvax.uncecs.edu Mars Hill, NC 28754