Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: linking to private frameworks

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@hidden 
<http://www.gandreas.com/> oh my!
Mad, Bad, and Dangerous to Know
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden
References: 
 >linking to private frameworks (From: Eric Ocean <email@hidden>)
 >Re: linking to private frameworks (From: Karin Kosina <email@hidden>)
 >Re: linking to private frameworks (From: Eric Ocean <email@hidden>)
 >Re: linking to private frameworks (From: Glenn Andreas <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.