How to build ppc glue stubs for 68k libs, when there is no includes ?

If we have some old 68k library as release only, without any single include file (no pragmas, no protos, nothing, just a simple blabla.library in the archive, and nothing), how to build blabla.l.main stub for ?

Is there any tool which can export lib offsets and name of function in, so i can create my own pragma/proto files, and make from them those stubs ?

Or maybe there some auto-tool present which i can just use to make stubs without worrying about includes ?

You can't. But then you can't use the library without the includes, so I don't see how you can build something for PPC that uses a 68k library you don't have the dev files for?

@Chris
Its for ppc binaries which use that library and functions from. Like we have in mui some 68k classes, the same situation for me (native dopus5 which can use bunch of 3d party 68k modules). Currently i make for them stubs, but for another ones (like xadopus.module in question), i can't.

Seems the only way as i think before its to make them all runs through EmulateTags(), so no stabs will need it at all.

Quote:

I think that's your best bet, and AFAIK also how datatypes.library gets around the same problem.

@Chris
Btw, we with Biro found author of xadopus.module ! Can you imagine, after 12 years of silence and some detective google work :) and he promise to give me sources in next days.

As i remember and know, xadopus.module was only one really necessary 3d party module for dopus5, making it native will solve all prolems too.

@kas1e:

Shouldn't each opus module use a standard plugin interface defined by opus itself? The glue code for each module would than be the same.

@Gazelle
Quote:

You are right, i just forget it :) The only difference is that each module have different name, and so inside of glue code names all the time different and for every module need to rebuild glue-stab with simple changes inside of them. But in general its the same interface, right. 68k version of xadopus.module works fine for me now on native builds, but as we will have soon sources i hope to make it native as well.

@kas1e

Hi (again?)

BTW there is another xad handler for DOpus5 written in ARexx, maybe is
"better" than XADopus.

http://jpv.wmhost.com/dopus-magellan2 ... _scripts/ArcHandlerEx.lzx

Nice site to visit too (DOpus5 related);
http://jpv.wmhost.com/dopus-magellan2

@Jabirulo
Quote:

ArcHandler is default thing in dopus5, yep. Just it have some bugs which also need to be fixed. But having choice between xadopus.module and archandler are good for sure. Besides Arexx scripts can be fixed by some 3d party coder later , while if we will not port xadopus.module now, we will loose it for ever, so better to make it also native and avail, so users can choice always.

Quote:
Sure, already aware of it. jPV already help me to build "normal default setup of dopus5", i.e. what users will have after they will just unpack dopus5 release, so to avoid woring with any settings, all will works as should just from first run.