Re: linking to private frameworks

FROM : Eric Ocean
DATE : Thu Sep 30 19:07:33 2004

Okay. Hmm. Thanks for the help. Is there a way to tell Ld not to 
resolve a symbol until runtime? Or perhaps that wouldn't work either. 
Is it just a convention that Ld won't reference the symbol, or is it an 
actual "Ld really can't find the symbol" situation? If it's the former, 
it makes sense that there would  be a flag to override that behavior.

It looks like runtime manipulation might be the way to go after all. 
Yuck.

Here's how I'm thinking of doing it. I'll create my own framework, 
ProKitPublic that subclasses each class in ProKit (conceptually), but 
in reality, subclasses from another class that shadows the classes in 
ProKit (a ProKit shadow class). The shadow classes are created using 
the headers from ProKit, but because they're defined in my ProKitPublic 
framework, I won't get linker errors.

Then, in each of my ProKitPublic subclasses, I'll generate code to 
pose_As the actual ProKit class during the -load method (or something 
more robust, like Omni's OBPostLoader). I won't be adding any behavior, 
so it shouldn't affect the program any, but it will quell the linker 
errors and allow me to subclass freely from my ProKitPublic subclasses 
and add functionality at will.

Does anyone see any problems with the above approach, or is there a 
better way? I would of course generate the code, so it's not going to 
involve the 30-odd ProKit classes being written by hand.

Regards,

Eric Ocean

On Sep 30, 2004, at 9:28 AM, Glenn Andreas wrote:

> At 9:13 AM -0700 9/30/04, Eric Ocean wrote:
> I own the application; I didn't write it.
>
> Here's the Ld command, and the error message. According to 
> RuntimeBrowser, the class does in fact exist in ProKit.
>
> Regards,
>
> Eric Ocean
>
> Ld /Users/test/Build/MySIMBL.bundle/Contents/MacOS/MySIMBL
>     cd /Users/test/Desktop/source
>     /usr/bin/gcc-3.3 -o 
> /Users/test/Build/MySIMBL.bundle/Contents/MacOS/MySIMBL 
> -L/Users/test/Build -F/Users/test/Build 
> -F/System/Library/PrivateFrameworks -filelist 
> /Users/test/Build/MySIMBL.build/MySIMBL.build/Objects-normal/
> MySIMBL.LinkFileList -framework Cocoa -framework ProKit -arch ppc 
> -bundle
> ld: Undefined symbols:
> .objc_class_name_NSProAlert
>
>
> Looking through the symbol information, .objc_class_name_NSProAlert is 
> a private symbol which means you can't reference it from an external 
> file.
>
> Granted, I have no idea how a class name can be a private symbol 
> (looking at other frameworks, all the classes's names are public 
> symbols), but that's what's happening.
>
> --
>
> Glenn Andreas                      <email_removed> 
> <http://www.gandreas.com/> oh my!
> Mad, Bad, and Dangerous to Know