Re: Using *optional* Frameworks in Xcode
Re: Using *optional* Frameworks in Xcode
- Subject: Re: Using *optional* Frameworks in Xcode
- From: Michael Marino <email@hidden>
- Date: Sat, 8 Dec 2007 16:01:54 -0800
Thanks for the information, it is very helpful and will be useful to
us. I should've been a little more specific as to what it is we're
trying to do. The framework we're using is essentially a third-party
hardware driver. After I submitted this to the xcode list, I thought
a little bit more and concluded that it might be good to remain
consistent with what our software has done in the past. That is, for
almost all of our hardware drivers, a kernel extension has been
written that can be installed completely separately. All the loading
of the extensions is done when those extensions are needed in the
executable. However, I'm a little hesitant to write a kernel
extension wrapper for a third-party framework and so I think it's a
better idea to write a bundle wrapper for the framework.
The bundle will be created with a principle class that acts as an
interface with the weakly-linked framework. This bundle can be
compiled and distributed with our kernel extensions (thus avoiding
licensing issues as we don't distribute the third-party code) but it
doesn't need to exist when the application is compiled.
I understand this adds an extra layer of complexity but it seems
necessary. If anyone has comments or suggestions, they would be
appreciated.
Mike
On Dec 8, 2007, at 1:23 PM, John Engelhart wrote:
On Dec 8, 2007, at 1:53 PM, Michael Marino wrote:
Hi all-
We develop a software of which a small part depends upon a third
party framework. That is, there is some additional functionality
that exists by having this framework but it is by no means
essential to the running of the program. I know that a framework
can be weakly linked if it might not exist on a machine, but we
would actually like to check its existence during the build
phase. Weakly linking requires a framework to exist on the
building computer.
While I haven't had a need to use this myself, this is one of those
things that got filed away in the back of the brain for "may be
useful later..."
Take a look at `man strip`, specifically a search for 'stub'. From
the 10.5 man page (this existed in 10.4, and I don't know if strip
changed much between the two):
-c Remove the section contents of a dynamic library
creating a stub library output file.
EXAMPLES
When creating a stub library the -c and -x are typically used:
strip -x -c libfoo -o libfoo.stripped
This strips out all the code and leaves with with a symbol husk.
These stripped versions are what you find under the /Developer/
SDKs/... directory, and allows you to target 10.4/etc while running
10.5.
Don't know all your details, but this might help if you could
distribute a relatively static (as in unchanging) stub for
developers to link against, instead of having to constantly update
and build the actual library.
Your other choice is to do the whole thing manually. `man dlopen`
and `man dlsym` for information about accessing a shared library at
runtime and retrieving the addresses to symbols and what not.
The primary references on the topic:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
DynamicLibraries/index.html
http://developer.apple.com/documentation/MacOSX/Conceptual/
BPFrameworks/index.html
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
MachOTopics/index.html
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
MachOTopics/Articles/loading_code.html#//apple_ref/doc/uid/TP40001830
I would also recommend reviewing http://developer.apple.com/
documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/
DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-
SW13 specifically. I haven't used the __attribute__((weak_import))
to mark anything as weak linked, but a quick pass at it gives me
the impression that assigning that attribute to a prototype of a
function (and probably any symbol) automatically makes the compiler
aware of the symbol and emit a weak link reference to the linker...
which suggests you might be able to put together a .h header with
all the symbols you want weak linked. If it really does work that
way (I just took a quick pass at it), that would seem like your
ideal solution.
Hope this helps.
PS- I got stuck plumbing the depths of the mach-o executable and
linking shenanigans, which is why I have all this info handy. I
didn't have the specific need for weak linking, it was more a
runtime loading of a dynamic library and static library issues.
_______________________________________________
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