• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Building framework with another framework
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building framework with another framework


  • Subject: Re: Building framework with another framework
  • From: Ryan Homer <email@hidden>
  • Date: Wed, 9 Jan 2008 11:30:04 -0500

When you use @executable_path/Frameworks, this puts you at a certain directory within your application bundle; this is where you are expected to put all your frameworks. Let's take a look at what you have:

Frameworks
	CCILib.framework
		CCILib (link)
		PkgInfo
		Resources (link)
		Versions
			A
				CCILib
				Frameworks
					MAAEL.framework (everything in here looks correct)
				Resources
			Current (link)

I added the "Frameworks" directory that I'm assuming is the parent directory.

Ok, so when you specify @executable_path/../Frameworks/ CCILib.framework, that path exists according to the above scenario. However, for the framework embedded in the other framework, that no longer holds true.

To get to the MAAEL.framework, the right path is now @executable_path/../Frameworks/CCILib.framework/Versions/A//Frameworks/ MAAEL.framework.

Therefore, for any dylib located in the CCILib.framework, you need @executable_path/../Frameworks/CCILib.framework/..
For any dylib located in the MAAEL.framework, you need @executable_path/../Frameworks/CCILib.framework/Versions/A//Frameworks/ MAAEL.framework/..


If you use otool -L <your dylib name here>, you can see the embedded paths. For example:

$ otool -L /usr/local/lib/libmimic.dylib
/usr/local/lib/libmimic.dylib:
/usr/local/lib/libmimic.0.dylib (compatibility version 1.0.0, current version 1.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)


Notice that the first entry is /usr/local/lib/libmimic.0.dylib, which refers to the dylib itself. To change this, you'd do this:

$ install_name_tool -id @executable_path/../Frameworks/ libmimic.framework/Versions/Current/libmimic.0.dylib libmimic.dylib

Notice I keep the exact name libmimic.0.dylib. If you do this, you must also make sure that this softlink exists in the same directory. I guess you can use the real name of the dylib to avoid having to create the softlink.

The other entries represent the other dylibs that this dylib needs. These are available on Mac OS X so you don't need to include them in your application bundle and you don't need to change the entries. If one of those remaining entries were not part of the OS and you needed to include them in your application bundle, you'd have to use install_name_tool with the -change parameter instead:

install_name_tool -change <current entry> <new entry> <dylib filename>. Ex:

$ install_name_tool -change /usr/lib/libgcc_s.1.dylib @executable_path/../Frameworks/libmimic.framework/Versions/Current/ libgcc_s.1.dylib libmimic.dylib

Note that you can use "A" or "Current" in the pathnames as Current is just a softlink. Probably better to use Current in case you later on have version B.

Some helpful links:
http://qin.laya.com/tech_coding_help/dylib_linking.html
http://lapcatsoftware.com/blog/2007/08/11/embedding-frameworks-in-loadable-bundles/
http://lists.apple.com/archives/Unix-porting/2004/Dec/msg00016.html

RH

On 7-Jan-08, at 4:19 PM, Steve Mills wrote:

(Sending to list. First went to Ryan only.)

On Jan 7, 2008, at 12:52:58, Ryan Homer wrote:

• Yes you are supposed to type @executable_path exactly like that; it will be replaced by the dynamic library loader at runtime.
• If your .h file is not copying over, it might be set as type "Project" and not as "Public".

Ah. That hidden setting has bitten me before. I don't know why they don't put it in plain view in the Get Info window where everything else is, rather than only in the contextual menu for the file. Unless I'm just not seeing it in some other more obvious location.


• In some cases, you do indeed want to look for your libraries in @executable_path/Frameworks, but in other cases, you need to check in @executable_path/Frameworks/CCILib.framework/Versions/Current/ Frameworks in order to find the MAAEL.framework. You may need to create a soft link from the first Frameworks directory so that MAAEL.framework also appears to be a sub-directory of it.
• I notice that one of the errors is "@executable_path/../ Frameworks/MAAEL.framework/Versions/A/MAAEL" which seems to confirm #3.

Hmm, can you explain in more detail what you mean? Pretend you're explaining it to a newbie please.


Steve Mills
Drummer, Mac geek
http://sjmills5.home.mchsi.com/


_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Building framework with another framework
      • From: Steve Mills <email@hidden>
    • Re: Building framework with another framework
      • From: Steve Mills <email@hidden>
References: 
 >Building framework with another framework (From: Steve Mills <email@hidden>)
 >Re: Building framework with another framework (From: Steve Mills <email@hidden>)

  • Prev by Date: Re: OpenGL documentation
  • Next by Date: IB bewilderment
  • Previous by thread: Re: Building framework with another framework
  • Next by thread: Re: Building framework with another framework
  • Index(es):
    • Date
    • Thread