vbcc 0.9f released

[plasmab]

Originally Posted by Leffmann

It looks like it's not finding everything it needs from amiga.lib, but I'm not sure. Try separating the M68K target and NDK headers and libraries, and let the M68K target directories have priority. That's how I've set mine up, and the program builds without errors here.

They are separate. One is located at $(NDK_LIBS) and one is under $(VBCC)/argets/m68k-amigaos/lib/ (which is defined in the config).

How is priority between those figured out?

[Hedeon]

In adding -lauto you removed -lamiga.

[plasmab]

My config file looks like..

-cc=vbccm68k -quiet -hunkdebug %s -o= %s %s -O=%ld -I$VBCC/targets/m68k-amigaos/include
-ccv=vbccm68k -hunkdebug %s -o= %s %s -O=%ld -I$VBCC/targets/m68k-amigaos/include
-as=vasmm68k_mot -quiet -Fhunk -phxass -opt-fconst -nowarn=62 %s -o %s
-asv=vasmm68k_mot -Fhunk -phxass -opt-fconst -nowarn=62 %s -o %s
-rm=rm -f %s
-rmv=rm %s
-ld=vlink -bamigahunk -x -Bstatic -Cvbcc -nostdlib -mrel $VBCC/targets/m68k-amigaos/lib/startup.o %s %s -L$VBCC/targets/m68k-amigaos/lib -lvc -o %s
-l2=vlink -bamigahunk -x -Bstatic -Cvbcc -nostdlib -mrel %s %s -L$VBCC/targets/m68k-amigaos/lib -o %s
-ldv=vlink -bamigahunk -t -x -Bstatic -Cvbcc -nostdlib -mrel $VBCC/targets/m68k-amigaos/lib/startup.o %s %s -L$VBCC/targets/m68k-amigaos/lib -lvc -o %s
-l2v=vlink -bamigahunk -t -x -Bstatic -Cvbcc -nostdlib -mrel %s %s -L$VBCC/targets/m68k-amigaos/lib -o %s
-ldnodb=-s -Rshort
-ul=-l%s
-cf=-F%s
-ml=1000

[plasmab]

Originally Posted by Hedeon

In adding -lauto you removed -lamiga.

Boc! Yes. I had them in my head as mutually exclusive. Fixed.

[phx]

Originally Posted by plasmab

They are separate. One is located at $(NDK_LIBS) and one is under $(VBCC)/argets/m68k-amigaos/lib/ (which is defined in the config).

How is priority between those figured out?

Not at all. Don't use the linker libraries from the NDK! vbcc's amiga.lib is a complete replacement.

And is there in any reason to call vlink directly? Usually this is done via the frontend "vc", which gets all the required options and paths from the config file.

vc +aos68k test.o -lauto -lamiga

[plasmab]

Originally Posted by phx

Not at all. Don't use the linker libraries from the NDK! vbcc's amiga.lib is a complete replacement.

And is there in any reason to call vlink directly? Usually this is done via the frontend "vc", which gets all the required options and paths from the config file.

vc +aos68k test.o -lauto -lamiga

I'm actually linking some C and ASM together. Normally do the vc thing. even then i'd need to know to use auto and amiga together.. feels like auto should imply -lamiga.. is there a case where you wouldnt want that ?

[phx]

Originally Posted by plasmab

feels like auto should imply -lamiga.. is there a case where you wouldnt want that ?

Including amiga.lib into auto.lib wastes disk space with redundant data. And when using the assembler inlines from proto/xyz.h to call library functions you often don't have to link with amiga.lib at all.

[plasmab]

Originally Posted by phx

Including amiga.lib into auto.lib wastes disk space with redundant data. And when using the assembler inlines from proto/xyz.h to call library functions you often don't have to link with amiga.lib at all.

Ok fair enough.

[plasmab]

OK i have a request / question about some of the new features in vbcc. The +aos68kr target seems like a great idea but i'm struggling to use it and it seems to be short on docs because its relatively new.

What i am trying to do?

Create an amiga kernel module in C...

I've managed to create the module but I cannot open any libraries in the vbcc compiled module without causing a crash. I figured that was because i need to keep my DosBase, SysBase etc as a local variable rather than a global but the linker complained about missing _SysBase and _DosBase when compiled with +aos68k(m). But when i try with +aos68kr the linker segmentation faults.

Any ideas? Latest stable versions of all the tools.

EDIT: I am not using -lauto or -lvc ... just -lamiga and trying to open graphics.library.

[plasmab]

Ok i solved my issue...

I need to use explicit __OpenLibrary(mySysBase, "graphics.library");

rather than the nice handy OpenLibrary() method.

I wonder if there should be (if there isnt already) a set of standard proto headers to make module / library development easier. There is so little docs on this that i found figuring this out extremely painful. What docs there are focus on SAS/C.