Path: utzoo!utgpu!attcan!uunet!husc6!uwvax!oddjob!ncar!mailrus!iuvax!bsu-cs!cfchiesa From: cfchiesa@bsu-cs.UUCP (Christopher Chiesa) Newsgroups: comp.sys.amiga Subject: Problems with Lattice C, part II: technical difficulties Keywords: bugs? trouble Message-ID: <3707@bsu-cs.UUCP> Date: 19 Aug 88 19:47:59 GMT Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 72 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:!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP