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.
      -Joshua
    • 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("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
    • 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.
      _Mark
    • 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.
      http://drpichon.free.fr/pmpd/
      best,
      wes