Using libraries with VBCC (Undefined Symbol)

[NoBrain2k]

Hi all

Despite years of (very on and off) programming in C this particular issue is alluding me. I would like to use either ptreplay or medplayer in my little C project, however I get complaints that symbols such as __LoadModule() aren't defined when linking. This is the case with both ptreplay and medplayer. It makes sense that the linker would complain about this, but I'm flummoxed as to the solution.

For the avoidance of doubt, I have of course included the proto .h files as required. I have tried passing the .library file to the linker but it complains that it is already a binary file (again, makes sense). I can not find any .lib files for ptreplay or medplayer.

Any suggestions?

[hooverphonique]

.library files are amiga os libraries, which you need to open using the os openlibrary operation(s).

Some libraries have stubs you can link in, that automatically open/close the amiga library in question and forward the calls to them, but I don't know if the ones you mention have such stubs also.

[NoBrain2k]

Thanks hooverphonique.


I understand that .library files are for Amiga OS. When I was trying to use it with the linker I was, admittedly, clutching at straws. OpenLibrary for (for example) medplayer.library appears to work perfectly in my compiled binary. I just can't generate a compiled binary that uses any of the library's own functions because the linker complains that I'm using functions that don't exist.

[nogginthenog]

The proto include will normally include an 'inline' include that contains inline assembly that loads libbase into a6 and calls the function.

If you're getting references to unknown functions then this is not working.

These headers are compiler specific. You cannot use GCC or SASC headers with VBCC.
There are tools to generate these headers from the FD files provided by library authors.

[hooverphonique]

yes, so in order to invoke e.g. __LoadModule() like any other C function, it would need a stub that forwards that call to the correct library vector, but it sort of sounds like your proto files only declare those stubs, not define them, thus the linker can't locate their implementation.

[NoBrain2k]

Originally Posted by nogginthenog

These headers are compiler specific. You cannot use GCC or SASC headers with VBCC.
There are tools to generate these headers from the FD files provided by library authors.

THIS is probably the thing I am missing. I have noticed the FD files whilst I was head-scratching but didn't know what they were for. A quick Google indicates that there is a fd2pragma tool included with VBCC.


I'll have a play tonight and see what I can do.


Thanks very much both of you.

[phx]

You need the FD file and the clib prototypes header. Assuming the library is xyz.library, generate the (portable) proto/xyz.h like this:

fd2pragma special 38 to include/proto xyz.fd

Then generate the assembler inlines (inline/xyz_protos.h):

fd2pragma special 70 voidbase to include/inline xyz.fd clib clib/xyz_protos.h

You will still be missing the stubs library, but usually the inlines are prefered anyway.

[NoBrain2k]

Originally Posted by phx

You need the FD file and the clib prototypes header. Assuming the library is xyz.library, generate the (portable) proto/xyz.h like this:

fd2pragma special 38 to include/proto xyz.fd

Then generate the assembler inlines (inline/xyz_protos.h):

fd2pragma special 70 voidbase to include/inline xyz.fd clib clib/xyz_protos.h

You will still be missing the stubs library, but usually the inlines are prefered anyway.

Thanks very much, after a bit of trial and error I finally managed to get this to work. I did actually switch to GCC because I was struggling a bit (and I always wanted to use GCC in linux anyway) but the process was much the same, with different 'special' numbers