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