Link mach-o library into jitter external
While trying to create a JitterODE (Open dynamics engine) bridge;
I've run into several problems:
1st: Code-warrior (IDE v4.5) can compile externals, but it won't let
me link in the mach-o library unless if the external is compiled as
mach-o; which yields a frenzy of compiler errors. Specifically, it
ends asking for "/usr/include" to go into the path, then pointing to a
file that only exists in the newer version of code-warrior (only
installed from curiosity, and it's the free student version -- so it
can't produce libraries).
2nd: Many failed attempts at linking the jitter libraries into XCode
(it just can't seem to understand the file format the library is in).
How can I convert the library (either ODE or Jitter) into a version
where each would be able to link into the same project?
Thanks,
--
~Michael();
You need to follow the strategy as demonstrated by the Apple Example
project: CFM_MachO_CFM. It might seem cumbersome at first, but it's
actually not that tough. A good deal of this can be marshaled by only
having a few entry points into your Mach-O bundle.
My simplethread extern also demonstrate one way to accomplish it from
a Max CFM extern. Keep in mind, you may need to do some header
munging or synthesis (as is the case for the necessary Mach-O pthread
calls in this example) to get this working.
Note that a Mach-O Universal Binary version of Jitter along with Mach-
O Jitter SDK is coming in the not too distant future (though I might
add, gcc produces markedly slower code than MWCC CFM in our tests so
far...sigh, I suppose this is the price of "progress". Hopefully we
can figure out some tricks to get near MWCC CFM performance on PPC).
Great project, btw. We've for a long time been talking about
investigating ODE for use within Jitter. I'm looking forward to
seeing your results.
-Joshua
Another thing which might help you out is an example of how we find
and dynamically load from an auxiliary bundle in the Max search path
(rather than the already loaded system frameworks shown in my
simplethread example). I've included the following from our loading
of the Mach-O Cg.framework from within CFM Jitlib.
void jit_gl_shader_framework_init_cg(void)
{
OSStatus err;
short path;
char name[256];
g_jit_gl_shader_cg_framework_ok = FALSE;
if (!nameinpath("Cg.framework", &path))
{
char outname[1024];
char natname[1024];
if (!path_topathname(path, "", outname))
{
FSSpec fs;
CFStringRef str;
CFURLRef url;
path_nameconform(outname, natname, PATH_STYLE_NATIVE,
PATH_TYPE_ABSOLUTE);
path_tospec(0, natname, &fs);
str = CFStringCreateWithCString(kCFAllocatorDefault, natname,
kCFStringEncodingASCII);
if (url = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, str,
kCFURLHFSPathStyle, true))
{
if (g_cg_bundle_ref = CFBundleCreate(kCFAllocatorDefault, url))
{
// post("jit.gl.shader: loaded CG framework.");
// include the bundle to cfm binding operations
#include "jit.gl.shader.cg.cfm.c"
// toggle global flag
g_jit_gl_shader_cg_framework_ok = TRUE;
}
broken:
CFRelease(url);
}
else
{
error("jit.gl.shader: error loading CG framework : no URL from
FSRef.");
}
CFRelease(str);
}
}
else
{
error("jit.gl.shader: unable to find CG framework.");
}
}
// jit.gl.shader.cg.cfm.h is of the following form for each function
pointer
// cgCreateProgram
typedef CGprogram (*tf_cgCreateProgram)(CGcontext ctx, CGenum
program_type, const char* program, CGprofile profile, const char*
entry, const char* *args);
tf_cgCreateProgram pf_cgCreateProgram=NULL;
// jit.gl.shader.cg.cfm.c is of the following form for each function
pointer
pf_cgCreateProgram = CFBundleGetFunctionPointerForName
(g_cg_bundle_ref, CFSTR("cgCreateProgram"));
if(!pf_cgCreateProgram) {
error("jit.gl.shader: unable to load CG framework function
'cgCreateProgram'");
}
This sort of thing can often be handled by some creative perl
scripting to make the appropriate files. I have a crummy one I hacked
together for some munging of the Max header files for other purposes.
If you want this as an example, let me know and I can send you that
monster off list.
Hope this helps.
-Joshua
Hi Joshua,
Do you have any information on these codegen regressions vs MWCC on
power pc? Is there increased function call overhead? Poor register
usage?
If you do find any glaring issues with gcc codegen vs MWCC please send
them my way in addition to whatever you would have normally done with
them. I would be happy to file copious bugs against the dev tools
team over here.
Obviously most helpful would be minimal snipets of code along with the
compiler options you're using and generated assembly from MWCC and gcc
and timing info. I am guessing you guys are doing this sort of
analysis anyhow, pushing it upstream to Apple might allow you to not
kludge quite so much.
_Mark
Hi there,
Check out PMDP by Cyrille Henry. Ali Momeni did a max port of the
objects. They use ODE to do physical modelling. There are
codewarrior projects that you can download.
best,
wes