Link mach-o library into jitter external

    Mar 29 2006 | 9:53 pm
    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();

    • Mar 29 2006 | 10:12 pm
      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.
    • Mar 29 2006 | 10:25 pm
      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(" loaded CG framework.");
      // include the bundle to cfm binding operations #include ""
      // toggle global flag g_jit_gl_shader_cg_framework_ok = TRUE; } broken: CFRelease(url); } else { error(" error loading CG framework : no URL from FSRef."); } CFRelease(str); } } else { error(" unable to find CG framework."); } }
      // 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;
      // is of the following form for each function pointer
      pf_cgCreateProgram = CFBundleGetFunctionPointerForName (g_cg_bundle_ref, CFSTR("cgCreateProgram")); if(!pf_cgCreateProgram) { error(" 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.
    • Mar 29 2006 | 11:03 pm
      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.
    • Mar 30 2006 | 12:08 am
      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