Path: utzoo!utgpu!watmath!clyde!att!rutgers!cmcl2!nrl-cmf!ames!lll-tis!lll-winken!csustan!koko!rayz From: rayz@koko.UUCP (Ray Zarling) Newsgroups: comp.sys.amiga Subject: Lattice 5.0 don't work (the way I want it to) Keywords: Doesn't use LC: assignment Message-ID: <866@koko.UUCP> Date: 1 Dec 88 22:27:20 GMT Organization: Calif. State Univ., Stanislaus, Turlock, Ca Lines: 38 [] I just got my upgrade to Lattice C v5.0, and I am bitterly disappointed! Yes, it seems to have all the goodies as advertised. Yes, it produces executables that seem to be typically 15% smaller than under 4.01. BUT... The only way I can run it on my system is to boot from the compiler disk! I try to run my Amiga with two floppies and a ram disk. That means I have a 99.99% full CLI disk in drive 0, my application in ram disk, and a disk with compiler executables and libraries in df1:. Under v[34].*, this worked fine--just assign LC: to an approriate subdirectory of my compiler disk, do other assigns for INCLUDE:, QUAD: and LIB:, and compile away! But 5.0 now requires the compiler passes lc1 and lc2 to be in your C: directory! (I tried putting the subdirectory with the compiler on the AmigaDOS path, but that didn't help.) I don't have room for several hundred more blocks of programs in my C: directory! I don't know if the other programs that lc wants to load also have to be there; lc2b, go (the optimizer), ...? If I try to configure the way I did under all the previous versions, lc just complains that it "Can't find lc1." Oh yes-- I *can* run the compiler passes separately, like the good ol' days: LC:lc1 -xxx blah; then later LC:lc2 -yyy blah... But you don't get the optimizer etc. this way, and anyways it's a pain! I called Lattice about this, and all they could suggest was to assign C: to the directory with the lattice executables! I suppose this will eventually work, but I will then have to put sys:c/ separately on my path, and I only got as far as trying it and discovering that RUN has to be moved to also be in the subdirectory with the lattice programs before I gave up in disgust at having to rework my entire environment. WHY? can't lc just look for lc1 etc. in LC: like it always has? Or like the documentation still implies that it does? Anyone know of a simple work-around for us poor people without hard disks who don't want to reboot just so they can do some compiling? --Ray Zarling ...uunet!lll-winken!csustan.EDU!rayz