use Perl

• Linking! Arggh! (Score:2)

  by acme (189)

  It looks like the binary isn't relocatable (unless I have a user called sherm ;-):
  
  dyld: /Volumes/JournalX/JournalX.app/Contents/MacOS/JournalX can't open library: /Users/sherm/Projects/CamelBones/build/CamelBones.framework/Versions/A/ CamelBones (No such file or directory, errno = 2)
  
  I'll try building from source.
  • Re:Linking! Arggh! (Score:1)

    by garth (867)

    Could you try again, with the newer version, and see if it works?
    
    You can grab it here [rubberband.org]
    • Re:Linking! Arggh! (Score:2)

      by acme (189)

      Looks great!
      
      Now, what should I do if I want to use a non-system perl, like my /Users/acme/bin/perl (bleadperl) in Camelbones?
      
      Cheers, Leon
      • Re:Linking! Arggh! (Score:1)

        by garth (867)

        You are exposing my lack of Cocoa/Framework knowledge here :-)
        
        I would guess that you need to re-compile the framework from source, pointing to the desired perl install, and making the installation location as "@executable_path/../Frameworks", as described in this article [cocoadevcentral.com]. Then to use that framework in the application, you would need to open up the bundle, and replace the current framework in JournalX.app/Contents/Frameworks.
        
        I haven't tried any of this, so it could be completely and utterly wrong. If I get
        • Re:Linking! Arggh! (Score:1)

          by Sherm (3537) on 2002.10.21 23:39 (#14104)

          That's pretty much how it's done. Pointing to the desired Perl install amounts to changing a couple of build settings. The article you pointed to is a great one.
          
          Although I'd like to point out that having a shared /Library/Frameworks/CamelBones.framework will eliminate the need to replace the framework in individual apps. If an app uses the shared framework, it doesn't care about what version of libperl that framework is linked against. That doesn't matter much, if you have only one Cocoa-Perl app; if you have a dozen, having to update them individually could be a pain.
          
          Fact is, I'm sitting firmly on the fence on this issue. Drag and drop installs are a long-standing Mac tradition, they're convenient for end users, and many folks are skeptical regarding Apple's Installer - rightly so, after the iTunes fiasco.
          
          On the other paw, embedding the framework in your .app bundle complicates things when libperl gets updated. Apple can't drag their feet on 5.8.0 forever - and many folks have taken matters into their own hands and compiled their own. When that happens - and sooner or later, it will - it will be much, much simpler for end users to simply install a single updated framework, than it will be for them to either download and install updated apps, or try to update all the embedded frameworks.

          Reply to This

          Parent