cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (08/20/88)
I've put this into a separate message from the previous, as it is really a totally different angle on a related problem... I've encountered some rather odd problems USING Lattice C v 3.03, even with the included "demo" C source programs. In order to get a successful compila- tion and linkage, I have to do all of the following (please bear with me): - perform the ASSIGNs recommended in the Lattice_C:s/install-c file i.e. LIB: , LC:, etc. (this is no problem; it's right up front, and I can cope with it.) - copy the source file into RAM: (to avoid a lot of disk-swapping in what's to follow; learned this the hard way) - ED the source file in RAM:, to give the include-file specs full path names, i.e. replace "#include /exec/types.h" with "#include lattice_c:include/exec/types.h" etc. If I don't do this, Phase 1 of the compiler tells me "file not found" on EVERY #include. - CD to the Lattice_C:include directory - if I don't do this, then even the "corrected" #includes, above, are still unable to find the files that they, in their turn, #include for their needs. - Invoke compiler phase 1, like so: LC:lc1 RAM:filename.c Once the "true" bugs (i.e. those preventing generation of a .q "inter- mediate" file) are corrected, this command merely generates thirty or forty WARNING messages, most, but not all, on the LAST LINE of the file. Most, but not always all, are "undefined tag" messages, and can safely be ignored, but I don't like that because someday I'm going to ignore something I SHOULDN'T. - Invoke compiler phase 2, so: "LC:lc1 RAM:filename.q" - this is the ONLY step that works "straightforwardly," so far. - CD to the Lattice_C:lib directory - prevents having to prefix "re- quired included file" names with "LIB:" in the ALINK step following. - Invoke the linker: LC:alink c.o,RAM:filename.o LIBRARY amiga.lib,lc.lib This works, and in most cases actually generates an executable module. However, I just tried the "Double For Nothing" Extra-Halfbrite mode demo program from the June '88 issue of AmigaWorld, and the 'alink' step claimed it couldn't find "_ CloseScreen", and refused to generate an executable until I deleted the "CloseScreen(Scrn)" statement from the source, and recompiled. THEN, it ran (and I found that MY 1000 does NOT support Extra_Halfbrite mode), but there was no CloseScreen to cleanly END the program, and I ended up being visited by the GURU ( 00000003 00030610, for who might find this information informative and helpful; I don't). A 'TYPE AMIGA.LIB OPT H' eventually turns up "_CloseScreen" deep in this library; so why can't Lattice C find it? (The only difference I can think of, is that the space between the underscore and the name of the function may be DIFFERENT between library and error message, but I'm FAR from sure of THAT.) I'm stumped. So. Does anyone here have ANY idea WHAT'S GOING ON? Is it possible that an upgrade to 4.0 (see my previous posting) would fix the problem? (The Extra_ Halfbrite demo program, for instance, clearly states "written with Lattice C v 4.0" - would that make that much difference??) Is my AMIGA.LIB simply corrupted, or what? I'm out of my experience here. Any input would be appre- ciated. Chris Chiesa recent graduate, Ball State University, CS Dept. -- UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP
tmpspa@eua4.ericsson.se (Stefan Parmark) (08/23/88)
In article <3707@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher Chiesa) writes: > > - ED the source file in RAM:, to give the include-file specs full > path names, i.e. replace "#include /exec/types.h" with "#include > lattice_c:include/exec/types.h" etc. If I don't do this, Phase 1 > of the compiler tells me "file not found" on EVERY #include. > > - CD to the Lattice_C:include directory - if I don't do this, then > even the "corrected" #includes, above, are still unable to find the > files that they, in their turn, #include for their needs. > I don't know if this goes for 3.03 too, but it works with 3.10 and 4.0. In my startup-sequence I have the statement 'Assign INCLUDE: DF1:include'. In my source code I have a '#include <exec/types.h>'. You remembered the '<' and the '>', didn't you? I think I recall that lc and lc1 could be called with the flag -i to specify an include directory. A simple lc file.c would probably not find the include files, but a lc -iINCLUDE: file.c would. >program from the June '88 issue of AmigaWorld, and the 'alink' step claimed >it couldn't find "_ CloseScreen", and refused to generate an executable until >I deleted the "CloseScreen(Scrn)" statement from the source, and recompiled. Well, _ CloseScreen isn't a valid function, but _CloseScreen is. I think there is a mysterious character before the C in CloseScreen(), that looks like a blank but isn't. I don't know if shift-space gives another character than space. It is very easy to press the shift key a little too soon. I suggest you try again, this time NOT pressing shift and space simultaneously. Why don't you write a file which contains all the commands and execute it, so you don't have to retype everything every time you compile. /Stefan Parmark