Shared library creation

Hi all

I've got a load of code that I'm trying to convert into a native amiga program and I've got a question about converting some shared utility function libraries. I've got them as dll and so files on windows and unix. Given the nature of the program, keeping them as shared objects is quite expensive as the program also consists of a load of plugins (as shared objects) and the overhead of reloading the utility libraries as shared objects for each one is too much. The libraries only export functions, no data, so they should be ideal candidates for normal amiga shared libraries.

After playing around with idltool, I'm starting to see how the xml and code fit together but I have a couple of questions.

1. Is the struct interface *self parameter a requirement? My code itself doesn't need it, since it doesn't have any private library specific data, and it would mean that I could just use the same prototypes that are in the library already. Or do I need to create a load of stub routines that include the self parameter that simply call the original prototype. For example, is it enough to have something like

void ConjugateQuaternion (Quaternion * const quaternion_p);

or must I have something

void ConjugateQuaternion (struct EPRIFace *self, Quaternion * const quaternion_p);


2. Looking at idltool it generates the c/h files from an exsiting xml file; for my situation I want to go the other way since I already have the c/h files and would need to generate the xml file. There about a 1000 functions so it could be quite time consuming to generate this interface xml file by hand, so I've started toying with the idea of writing a parser program to scan the header files and produce this xml file. Am I duplicating something that already exists here?

cheers

billy

The best thing to do is broadly follow the instructions in the bz2.library example archive. Unfortunately I can't find the download of that any more (which I thought was on Joerg's website). The next best thing is iconv.library - the files in the source directory are all that are needed to convert the libiconv.a into an iconv.library.

It's easier just to hand-edit those files for a new project, than follow the original notes anyway.

@Chris

I notice your webp_lib.lha archive also has code that should help demonstrate how make a .library. I might use that example and try making one myself sometime, just for curiosity's sake.

@MickJT

Yes, the WebP code is based on the iconv.library code (it may have gone through some interim revisions).

libwebp has a lot more functions though (and the API annoyingly gets tweaked with every release). However, you should be able to build a newer webp.library by building libwebp, copying over the amiga_lib directory, and then running make -fmakefile.lib in there.

Best case that will work, but most likely you'll need to scour through the libwebp includes to update the webp.library ones. Any functions that have been removed or changed need to be stubbed/redirected and new ones added to the end of the list. Then the static stub library needs to be updated in sync (functions there need to match the libwebp ones, no need for old stuff to hang around).

AFAIK only my webp.datatype currently uses webp.library (cwebp and dwebp should be rebuilt against the new one of course) so if you break it it's unlikely to be noticed
The WebP datatype only uses a couple of functions (can't remember which ones now)

It's unfortunately a very dull process, which is why I don't update webp.library unless I'm prompted to do so. If I learn they've added meta-data I'll do it just so I can add that to the datatype. Until then it can wait!

I had a look at the amiga specific code in webp_lib, and on 2nd thought it might be a bit beyond me to do :)

@MickJT

It's only the headers you really need to change. If you're converting for a new project then all the IWebP, WebPBase, WebPIFace etc need to be changed, and of course the list of functions (in several files). It's not hard, just monotonous.

@Chris

Quote:

Thanks for this, I'll take a look and see how I get on with these.

cheers

billy

Hello

You can generate the .xml from a .sfd file = simpler
dont remenber if it is fdtrans or idltool that can do that
Also have a look to Aminet/wazp3d for a library source...

Alain Thellier

@Alain
Quote:

Its fdtrans:

Quote:

But also can be done via fd2pragma if .fd in use:

Quote:

@MikeJT

It's not that hard, just update the JMP table, and Write a few stubs, the JMP table is not needed for new programs, only for old programs, the interface table has to be filled inn, and self-variable has to be added to all functions.

As for the header files you can look at existing header files for inline and not, in SDK.

Yes it lot of work but not too complicated.