Error Number 232

External developers... This forum's for you!

Error Number 232

Postby sctell » Mon Oct 31, 2011 8:11 am

Hi,

I have been trying to incorporate F-Script into an external and I keep getting:

Error Number 232.

Unable to link Mach-O external.

Any guidance please.

Thanks

terry


PS This is being compiled with Xcode 3
sctell
 
Posts: 1134
Joined: Sun Jul 06, 2008 10:41 am

Re: Error Number 232

Postby codegreen » Mon Oct 31, 2011 5:09 pm

sctell wrote:I have been trying to incorporate F-Script into an external and I keep getting:

Error Number 232.

Unable to link Mach-O external.

Any guidance please.

This error is returned when NSLinkModule fails as SC tries to prepare what it thinks is the appropriate fragment for the current CPU from your Mach-O external for execution. Often this indicates that a framework you've referenced either can't be found in the default location(s) or isn't compatible with the current OS.

Have you downloaded a version-appropriate copy of FScript.framework and dragged it into your /Library/Frameworks/ (or ~/Library/Frameworks/) folder?

-Mark
codegreen
 
Posts: 1540
Joined: Mon Jul 14, 2008 11:03 pm

Re: Error Number 232

Postby sctell » Tue Nov 01, 2011 1:35 am

codegreen wrote:Have you downloaded a version-appropriate copy of FScript.framework and dragged it into your /Library/Frameworks/ (or ~/Library/Frameworks/) folder?


It's embarrassing, :oops:

Thanks Terry

PS.

This is looking really promising as an external for direct access to Cocoa.

For example this script displays the picture taker panel using this FScript code which I attached to a userProperty called IKPictureTaker.

Button Script:
Code: Select all
on mouseUp
put the IKPictureTaker of this cd into tScript
put FScript("execute",tScript) into cd fld 1
end mouseUp


User Property:
Code: Select all
IKPictureTaker pictureTaker orderFront:nil



Can you foresee any issues?

All the best

Terry
sctell
 
Posts: 1134
Joined: Sun Jul 06, 2008 10:41 am

Re: Error Number 232

Postby codegreen » Tue Nov 01, 2011 8:19 am

Can you foresee any issues?

Not off the top of my head (beyond the normal warnings about using Cocoa in externals that get unloaded).

I started investigating writing an OSA wrapper for F-Script last spring (before I got derailed by family-related medical issues) so that it could integrate with SuperTalk's script() function, but that seems to be something of a black art (due to sparse documentation). In retrospect though it's probably more sensible just to hard code a special case for F-Script handling that bypasses the OSA layer.

Given the use-it-as-you-like licensing terms, building F-Script support in could obviate the need to persuade users to install the F-Script framework (we'd just stick it inside the app bundle and load it directly) and also sidestep possible crashing issues with unloading Cocoa code.

At this point it's unlikely that feature will arrive (if at all) before Q2 of next year -- I've already got a lot of other irons in the fire, and we have to do a LOT more testing than you would before we let something this big and hairy loose in the wild... ;-) So in the meantime unless you find some nasty gotcha, a wrapper external sounds like it would be a really awesome tool! If you manage to figure out how to do enough cool stuff with it, perhaps Scott will decide to fast-track the feature...

-Mark
codegreen
 
Posts: 1540
Joined: Mon Jul 14, 2008 11:03 pm

Re: Error Number 232

Postby sctell » Wed Nov 02, 2011 11:15 am

Hi Mark,

I don't know if you have read the other thread but I have an external sort of working but it rely's on the framework being in the Library/Frameworks folder.

I would like to incorporate the framework into the external bundle and have managed to get it to copy in but whenever the external is loaded I still get the error.

I have been reading on the internet about frameworks but don't seem to be able to sort it.

In Xcode 3 I have

Placed the framework in frameworks
Done a copy files phase

On inspection the framework is in the externals bundle but SC says it can't load it.

Would you know what I am doing wrong or give me some pointers?

All the best

Terry
sctell
 
Posts: 1134
Joined: Sun Jul 06, 2008 10:41 am

Re: Error Number 232

Postby Dave_Higgins » Wed Nov 02, 2011 4:00 pm

I have a feeling that this could be tricky. My guess is that the root of the problem goes hand-in-hand with NSBundle MainBundle referring to SC's main bundle, as opposed to the external's bundle (which is no longer a bundle when imported as a data fork external, I presume). I have a feeling that it's being lost on the import (or load from bundle), therefore relying on all external frameworks being in one of the Library paths.

The only workaround that I can think of is not elegant, either... I see in my ~/Library/Frameworks folder there are plenty of third party frameworks that were placed there by various apps, but in order to check that FScript's framework is there (and place a copy there if it's not (assuming their license permits it (haven't looked))), you would have to do this with startup/openProject and have SC (via your project) do this before you load the bundle (or call it when run as an embedded external).

This might be acceptable as the external develops (or more like as various FScripts are developed) until Mark can get back to it and work out some sort of mechanism that he spoke of earlier... A caveat can be given that any project using this must test for the presence of the framework in one of the Library locations.

Of course, as usual, Mark chimes in and corrects me when it comes to something like this, so... Have at it. :roll:
My two favorite teams are Detroit and whoever's playing Chicago.
User avatar
Dave_Higgins
 
Posts: 454
Joined: Mon Jul 07, 2008 9:50 am
Location: Dark Side Of The Moon

Re: Error Number 232

Postby codegreen » Wed Nov 02, 2011 8:48 pm

Dave's right that the Framework has to be in dyld's search path if you want it to be found and linked automagically when your external is prepared, but there's more devious options.

You can use CFBundle services to load the framework bundle from a folder within your external's bundle dynamically and then snag function pointers to the routines you want using CFBundleGetFunctionPointerForName(s). This way the dynamic linker doesn't have to find the symbols itself. It's pretty straightforward but a bit tedious...

You might also be able to trick dyld into looking in a subfolder of your external's bundle using some environment variables (DYLD_FRAMEWORK_PATH and @loader_path/) before loading your external to add that folder to its search path (see the dyld man page).

I know the first technique works, but obviously it's more of a pain (since you have to write a bunch of ugly glue code). The second is probably worth trying first for that reason alone...

-Mark
codegreen
 
Posts: 1540
Joined: Mon Jul 14, 2008 11:03 pm

Re: Error Number 232

Postby Dave_Higgins » Wed Nov 02, 2011 11:19 pm

codegreen wrote:I know the first technique works, but obviously it's more of a pain (since you have to write a bunch of ugly glue code). The second is probably worth trying first for that reason alone...

And it sounds like either one of those solutions will require the external to tag along as a bundle, as opposed to being able to use it as an embedded data fork external (unless you want to embed the external and still carry the framework along, which seems to defeat the purpose). :(

I could see this maybe working out a bit easier if you're publishing a standalone where you could stash the framework and/or bundle external inside it's package, perhaps.
My two favorite teams are Detroit and whoever's playing Chicago.
User avatar
Dave_Higgins
 
Posts: 454
Joined: Mon Jul 07, 2008 9:50 am
Location: Dark Side Of The Moon

Re: Error Number 232

Postby sctell » Thu Nov 03, 2011 12:07 am

codegreen wrote:You might also be able to trick dyld into looking in a subfolder of your external's bundle using some environment variables (DYLD_FRAMEWORK_PATH and @loader_path/) before loading your external to add that folder to its search path (see the dyld man page).


I have tried using in installation directory with @executable_path/../Frameworks

and

@loader_path/../Frameworks

I am not sure I have used them correctly however.

I have placed them in the installation directory in Xcode when I build the external. Is this correct?

Also I have read suggestions with nothing definite that the build of the framework may also need adjusting similarly, so I have also tried these environment variables here as well. Is that correct?

What path does loader_Path and executable_Path actually return in relation to a SC external?

Any help gratefully received.

All the best

Terry
sctell
 
Posts: 1134
Joined: Sun Jul 06, 2008 10:41 am

Re: Error Number 232

Postby witness » Thu Nov 03, 2011 1:01 am

codegreen wrote:You might also be able to trick dyld into looking in a subfolder of your external's bundle using some environment variables (DYLD_FRAMEWORK_PATH and @loader_path/) before loading your external to add that folder to its search path (see the dyld man page).


This is probably the best approach for a bundle external. @loader_path (when used in the installation path build setting for the *framework*) will be replaced with the path of your external's actual library file (not the .framework folder). So you should be able to build the proper relative path to that.

By the way, to look up resources in a bundled external, you may be interested in playing with [NSBundle bundleForClass: [SomeObjCClass class]] which lets you look up wherever you are. This will probably resolve to SuperCard for a data fork resource ("star") external, but that means you could import it and then dump the resources in a standalone's Resources folder, if you want to. Generally you just want to leave it bundled so the bundle points to your external, of course.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are Everywhere..."
http://www.zathras.de
User avatar
witness
 
Posts: 55
Joined: Thu Jul 17, 2008 2:24 pm

Re: Error Number 232

Postby witness » Thu Nov 03, 2011 1:09 am

sctell wrote:I have tried using in installation directory with @executable_path/../Frameworks and @loader_path/../Frameworks

I am not sure I have used them correctly however.

I have placed them in the installation directory in Xcode when I build the external. Is this correct?


Not sure that will work. First, make sure you specify this setting in the frameworks, not in your external. Then link to the frameworks normally, and the built external will expect them to be in that folder. This is not a setting you apply to the external.

This (slightly older) screencast I did ages ago might help explain stuff a little:

http://vimeo.com/17076097
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are Everywhere..."
http://www.zathras.de
User avatar
witness
 
Posts: 55
Joined: Thu Jul 17, 2008 2:24 pm

Re: Error Number 232

Postby sctell » Thu Nov 03, 2011 4:47 am

Uli,

Thanks for the advice.

Watched your video. It does seem a little clearer now.

I have changed the settings for the Framework build and it now works.

I originally changed the project settings and that did not work.

Not sure why? but will have a think.

Anyway, the good news is, it seems to be working with the framework now packaged in the external.

Not tried it yet but I believe it should work if you place the external in a standalone SC app as long as you load the external from the correct path.

All the best and thanks once again.

Terry
sctell
 
Posts: 1134
Joined: Sun Jul 06, 2008 10:41 am

Re: Error Number 232

Postby Dave_Higgins » Thu Nov 03, 2011 6:23 am

Fantastic news... I had a feeling that you'd work it out.

Uli-Mon... I watched that video, too... Interesting how you sound just like a computer in it. :lol: ... I'm curious... Are there any more in that list that are yours?
My two favorite teams are Detroit and whoever's playing Chicago.
User avatar
Dave_Higgins
 
Posts: 454
Joined: Mon Jul 07, 2008 9:50 am
Location: Dark Side Of The Moon


Return to Xcode and the Internals Toolbox

Who is online

Users browsing this forum: No registered users and 1 guest