Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!agate!bionet!arisia!roo!corinth!carpente
From: carpente@corinth.uucp (Michael A. Carpenter OSBU North)
Newsgroups: comp.sys.amiga.tech
Subject: SAS/C 5.10
Message-ID: <549@roo.UUCP>
Date: 4 Oct 90 16:46:43 GMT
Sender: news@parc.xerox.com
Reply-To: carpente@corinth.UUCP (Michael A. Carpenter OSBU North)
Distribution: comp.sys.amiga.tech
Organization: Xerox Palo Alto Research Center
Lines: 32

Hello netters,

This is my first message to the netnews, so please go easy on me if
this question has been asked before or if I screw something up
terribly.

Background:  I got SAS/C 5.10 (used to be Lattice) recently.  For
me this is an upgrade to version 3.something (I haven't exactly been
keeping up, have I?).  So this may also happen in Lattice 5.0, I 
don't know.  I am running on an A1000 with just two floppy drives
(no hard disk) and two MB RAM.  The way I would like to run is this -
make a recoverable RAM disk and put the C: commands, the compiler, 
linker and LMK in RRD:C, then put the floppy with the libraries and
header files in one drive and the floppy with my source code in the
other drive.  (This means that my workbench disk is not in any drive,
but that should be ok, because I have C: assigned to the RAM disk.)

My problem is:  When I compile, the CLI hangs after the compiler gives
its' banner and reports "Compiling hello.c".  On the other hand, if I
put my WorkBench disk in and put the source in RAM, then it works 
fine, but the first thing it does during a compile is access the Work-
Bench disk!!  So if I want to compile my source from floppy, I have to
put the WorkBench disk in and swap it and the header/library disk.

My question is:  WHY??  What is it trying to get from the WorkBench
disk.  I tried moving the important stuff to RAM and reassigning L:,
FONTS:, S:, etc., but it still wants that WB disk.  How can I get
around this problem?  

Thanks in advance for any help.  

Michael Carpenter