• 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 a C library Objective-C wrapper framework
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building a C library Objective-C wrapper framework


  • Subject: Re: Building a C library Objective-C wrapper framework
  • From: Jens Alfke <email@hidden>
  • Date: Mon, 14 Jul 2008 08:30:20 -0700


On 14 Jul '08, at 2:00 AM, Sebastian Nowicki wrote:

What happens is that I try to #import <MyFramework/MyFramework.h>, and gcc complains that it can't find theclib.h. "theclib.h" is found in MyFramework/Headers/theclib.h, but it's of course only looking in the default header search paths.

Ideally, your framework should hide the C library by not #including its header from its own public headers. Which means not using any types defined by that library in your headers. It's usually possible to do this, but it can get a little tricky sometimes.


I'd like some guidance on how to go about doing this properly. I'm obviously not setting the install_path right - I'm completely confused about that.

This part confuses me too, to be honest. You need to tell the linker where the dylib will be found at runtime, so it can load it. That path will be inside your framework's bundle, not in /usr/local/lib or wherever the dylib normally gets installed by its makefile. The two ways to do this are to build the dylib with a different install location, or to tell the framework's link step to substitute a different location. The latter is probably a lot easier (since it avoids messing with the 3rd party makefiles) but I don't know how to do it … hopefully someone here can clarify that.


I come from a linux background so this is really confusing for me. On linux I just compile against the lib with the assumption that the lib will constantly stay in that place - plain and simple.

Yeah, this is unfortunately the price the developer pays for making life easier for the end user (i.e. by making self-contained apps that can be installed and uninstalled simply by copying them, without having to use an installer or package manager.)


—Jens

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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 a C library Objective-C wrapper framework
      • From: Sebastian Nowicki <email@hidden>
References: 
 >Building a C library Objective-C wrapper framework (From: Sebastian Nowicki <email@hidden>)

  • Prev by Date: Xcode 3.1 - Duplicate DocSets (that aren't)
  • Next by Date: Re: adding framwork to x code
  • Previous by thread: Building a C library Objective-C wrapper framework
  • Next by thread: Re: Building a C library Objective-C wrapper framework
  • Index(es):
    • Date
    • Thread