UB standalone: executable bit not set, support folder not found


    Jun 27 2006 | 12:36 am
    OK, I've reinstalled 4.6b11, and when building a standalone, the runtime executable bit still isn't being set. After fixing that, the support folder isn't being found when the standalone is run. Details:
    PPC (G4), Mac OS X 10.4.3, CFM support not installed
    All patches and builds are on a separate partition, not the boot partition. MaxMSP is installed in /Applications on the boot partition.
    No 3rd-party MaxMSP objects or extensions installed.
    "Ignore permissions" is not set on the build partition.
    Patch to build:
    Build script: open thispatcher
    Result: Starting Build for support folder.app... Processing script... Copying External folder Copying External standalone Investigating MidiSetup Input.pat... Saving Patcher MidiSetup Input.pat... Copying External umenu Investigating MidiSetup Output.pat... Saving Patcher MidiSetup Output.pat... Copying External umenu Investigating MidiSetup Buttons.pat... Saving Patcher MidiSetup Buttons.pat... Copying External panel Copying External ubutton Finished script.
    The resulting "support folder.app" will not run:
    ls -l total 21840 -rwxr-xr-x 1 john john 11181736 Jun 24 04:59 support folder chmod +x ./support folder
    The app now runs, and prints this error:
    • error: folder: ./support: not a folder
    It gets curiouser:
    Change the original patch (add a comment). Build it again, answering "yes" to the "replace" dialog to overwrite the original standalone.
    The build script produces no errors, but the .mxf and the support folder are placed in the same folder as the original Max patch, not in the application bundle.
    Run "support folder.app" and the same error is produced, but the app does not include the added comment.
    Any other pertinent details I can add?

    • Jun 27 2006 | 11:37 am
      My guess is that this is going to end up being something related to the your having the patches etc.. on the separate partition.
      Have you tried with that stuff located on the boot partition?
      Dan
      -- Dan Nigrin Defective Records 202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X http://www.defectiverecords.com http://www.jackosx.com
    • Jun 28 2006 | 2:48 am
      Quote: Dan Nigrin wrote on Tue, 27 June 2006 23:37 ---------------------------------------------------- > My guess is that this is going to end up being something > related to the your having the patches etc.. on the separate > partition. Have you tried with that stuff located on the boot > partition?
      A - Example patch on non-boot partition, build to boot partition: Builds successfully. Is executable. Runs, but takes quite a while (15+ seconds, beachball) to start. Can't find ./support folder.
      Build-replace replaces correctly. Runs as above.
      B - Original patch on boot partition, build to boot partition: Same as above.
      Rats.
    • Jun 28 2006 | 12:03 pm
      Am 28.06.2006 um 04:48 schrieb John Pitcairn: > Runs, but takes quite a while (15+ seconds, beachball) to start. > Can't find ./support folder.
      The default path now points to where the app bundle is, not to the collective inside of it. So ./yourapp.app/Contents/support should work.
      However: The searchpath also changed back to OS9 behaviour, meaning that the folder in which the app resides is added to the searchpath on startup. Great thing if you want to provide a folder with a few soundfiles and you want to load them easily with their names, not so great if you want to make a well behaving self-contained OS X app. I built my first app to the desktop, and had to force-quit after minutes of beachball. The application folder also isn't a good place for a standalone built with the beta, as it will recursivly search the application folder (and all apps in there are folders with subfolders to Max!).
      It would be cool if the standalone object could get an option to limit the searchpath to the bundle itself, apparently unchecking "Search for Files Not in the Application's Collective" doesn't do it (plus it would be nice to be able to provide extra files outside the collective but inside the bundle).
      best, g.
    • Jun 28 2006 | 10:47 pm
      Quote: grg wrote on Thu, 29 June 2006 00:03 ---------------------------------------------------- > The default path now points to where the app bundle is, not to > the collective inside of it. So ./yourapp.app/Contents/support > should work.
      And indeed it does, thanks. I stupidly hadn't considered the new default path.
      It still won't build as executable to a non-boot partition however, and build-replace to a non-boot partition puts the .mxf and support folder in the same folder as the original patch.
      > However: The searchpath also changed back to OS9 behaviour, > meaning that the folder in which the app resides is added to > the searchpath on startup. Great thing if you want to provide > a folder with a few soundfiles and you want to load them > easily with their names, not so great if you want to make a > well behaving self-contained OS X app.
      Indeed. It's traversing any aliases in the folder too. I'd vote for this behaviour to be reverted - Mac users expect to be able to put an app in the /Applications folder (and I tell them to do so), or indeed anywhere, and not have that affect how long it takes to start up.
    • Jun 29 2006 | 12:14 am
      OK, I have a UB that functions perfectly on PPC. My next problem is mxj syscommand (as shell replacement) not working on Intel. See you in the Java forum...