UB standalone: executable bit not set, support folder not found
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:
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#S creator ????;
#S statusvisible 0;
#S noloadbangdefeating 1;
#S useownplist 0;
#S preffilename "Max 4 Preferences";
#S overdrive 0;
#S allwindowsactive 0;
#S searchformissingfiles 1;
#S usesearchpath 0;
#S cantclosetoplevelpatchers 1;
#S audiosupport 0;
#S midisupport 1;
#P newobj 278 200 58 196617 standalone;
#P newex 194 198 50 196617 print;
#P newex 193 171 50 196617 folder;
#P message 192 143 103 196617 types fold , ./support;
#P newex 192 109 50 196617 loadbang;
#P connect 2 0 3 0;
#P connect 1 0 2 0;
#P connect 0 0 1 0;
#P window clipboard copycount 5;
Starting Build for support folder.app…
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
The resulting "support folder.app" will not run:
-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?
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?
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
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
A – Example patch on non-boot partition, build to boot partition:
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.
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
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
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).
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.
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…