dss@cubsvax.UUCP (David Silver) (09/29/86)
When using the my.lib library, Matt suggests linking with Astartup.obj
rather than Lstartup.obj. Whenever I use Astartup.obj and amiga.lib
(leaving out lc.lib) I get the message:
Warning: Undefined symbols
__xcovf
__base
from Blink.
Whenever I link with Lstartup.obj, and libraries my.lib+amiga.lib+lc.lib
I get the message:
ERROR: Multiply defined symbol '_IntuitionBase'
first defined in file 'LIB:my.lib'
One way to eliminate this error is to place lc.lib before my.lib on the
command line.
I'd love to get all this ironed out so that I can get to some REAL work.
Thanks for any help!
--
David Silver
{philabs,rna}!cubsvax!dss
cubsvax!dss@columbiadillon@CORY.BERKELEY.EDU (Matt Dillon) (09/30/86)
I could just kill Lattice. In the next release I will include my own startup file. Try this link sequence: alink(or blink) Astartup.obj+........ library my.lib+amiga.lib+lc.lib Note that lc.lib is in the list, but last in the list. -Matt
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (10/03/86)
In article <546@cubsvax.UUCP> dss@cubsvax.UUCP (David Silver) writes: > >When using the my.lib library, Matt suggests linking with Astartup.obj >rather than Lstartup.obj. Whenever I use Astartup.obj and amiga.lib >(leaving out lc.lib) I get the message: > >Warning: Undefined symbols > __xcovf > __base SOME GENERAL RULES FOR LINKING 1. Full Lattice compile and link Gives you access to all LC.lib functions (fopen, strcmp, etc.) Also gives you a small stdio window on WB startup. This is required if you want to start a program that uses printf(), getchar(), etc from WorkBench. Alink LStartup.obj, your.o TO your.ld LIBRARY LC.lib, Amiga.lib 2. Full Lattice compile and link with no WB startup window First, compile _main.c using the flag -dTINY (means #define TINY) on pass 1 (LC1) of the compiler. Then ... Alink LStartup.obj, _main.o, your.o TO your.ld LIBRARY LC.lib, Amiga.lib 3. Amiga only compile and link No access to LC.lib. No default window on WB startup This is my favorite. (produces much smaller code) You must use the -v flag on pass 2 (LC2) of the compiler when you compile your C modules. This keeps Lattice from adding its stack-checking code to your functions and therefore gets rid of the unresolved external references to __xcovf and __base. Note that you must also use the -v flag when compiling C modules for something that can't have any startup code, for example printer drivers, devices, libraries. You must also write you code so it does not require any functions that are only in LC.lib (i.e. most of the functions in the C manual). Also, don't use any of the lattice/ headers. Amiga.lib contains a number of useful C functions you can use such as printf, sprintf, getchar, putchar, fprintf, fgetc, fputc. (The printf's don't handle floating point) Note that this link will not resolve non-power-of-2 multiplication or division (unresolved _CXM22 and _CXD22 or something like that). If you get these unresolved, use method 4 (below). I usually use direct AmigaDos file functions, write my own string functions, and use Amiga.lib's printf and getchar if needed. Alink AStartup.obj, your.o TO your.ld LIBRARY Amiga.lib 4. Amiga compile and link with LC.lib Same as above but resolves things like non-power-of-2 multiplication and division by pulling in parts of LC.lib. (makes code a bit bigger) Note that some printer drivers require this method (minus the startup code) because their Render routines need the LC.lib math. Write your code as in #3, compile with -v on LC2 and ... Alink AStartup.obj, your.o TO your.ld LIBRARY Amiga.lib, LC.lib ------------------------------------------------------------------------- Hope this clears up some of the confusion. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
hull@hao.UUCP (Howard Hull) (10/04/86)
In article <547@cubsvax.UUCP>, dss@cubsvax.UUCP (David Silver) writes: > > When using the my.lib library, Matt suggests linking with Astartup.obj > rather than Lstartup.obj. Whenever I use Astartup.obj and amiga.lib > (leaving out lc.lib) I get the message: > > Warning: Undefined symbols > __xcovf > __base > > from Blink. I got some undefined stuff, too. Only, I think what I had was _base and some intuition stuff. I had used the now famous Fish cc program to compile all the library sources (except for the ".asm" stuff, of course). I was even aware enough to make sure I called out "AStartup.obj" rather than "LStartup.obj" as the first FROM file, and that I cited lc.lib last in the list (as you first did) when I linked the Shell itself. I carefully re-read the instructions that came with the first posting of the Library and couldn't see that I'd done anything wrong. Then I decided to use the instructions Matt included with the *Shell sources* (that's the file "instructions.txt") for compiling the library. These instructions said: lc1 -i$incdir/ -i$incdir/lattice/ $y lc2 -s -v $y which in my system becomes LC1 -i:include/ -i:include/lattice/ xsnarf LC2 -s -v xsnarf if I don't write an LMK file for Lattice Make, or, if do use Lattice Make, I can write a small makefile for doing them one at a time: $T.o: LC1 -i:include/ -i:include/lattice/ $T LC2 -s -v $T and invoke the make with LMK T=xsnarf to compile the xsnarf.c routine (where one replaces "snarf" by whatever element of the library one wishes to compile). One comment I should add about this recommended method is that it doesn't (without some additional implementation) use the Ram: disk as the clever "cc" program does. But many of you out there know what to do about that (I don't, but then so far it hasn't been worth the trouble for me to figure it out). I actually looked up the -s and -v flags to see what was important about them, but I think what the manual said (roughly) is that -v was a verbose flag to printout the gory details of the proceedings, and the -s flag was one which caused all of the compiled code to load in one chunk. It said that this might make it less likely that the code could get loaded in a badly fragmented memory, but had some (unremembered) advantages otherwise. I don't know why I had to use it for Matt's Shell. Maybe he knows... Regards, Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull