Re: Dynamic loading of a third party .dylib [ENLIGHTENED]
Re: Dynamic loading of a third party .dylib [ENLIGHTENED]
- Subject: Re: Dynamic loading of a third party .dylib [ENLIGHTENED]
- From: "email@hidden" <email@hidden>
- Date: Sun, 8 Aug 2010 10:33:02 +0100
On 8 Aug 2010, at 00:22, email@hidden wrote:
> Thanks Alexander
>
> Your reply prompted me to follow up on calling dlsym().
> All is revealed below.
>
> http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html
Looking through the docs quoted above (very informative) and recent postings on the list (ahmm..) it would seem that a script phase invocation of install_name_tool is the way to go rather rather dlopen().
My dylib is definitely a dependent library that requires global scope.
Using dlopen() on an obj-c library also requires that library classes are accessed using the rt function objc_getClass().
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/UsingDynamicLibraries.html illustrates the essential difference between using dependent and dynamic loading:
"An image that uses dynamic libraries as runtime-loaded libraries is smaller and loads faster than the image using the same libraries as dependent libraries. The static linker doesn’t add information about the runtime-loaded libraries to the image. And the dynamic loader doesn’t have to load the library’s dependent libraries when the image is loaded. However, this flexibility comes at a price. Before an image can use a dynamic library that is not one of its dependent libraries, it must load the library with dlopen and get the address of each symbol it needs with dlsym. The image must also call dlclose when it’s done using the library.
"
Here is the sample from the docs :
(http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW10)
to illustrate what is required to access a single dynamically loaded library function with a signature of char *bla_name(void):
#include <stdio.h>
#include <dlfcn.h>
int main(void) {
void* Bus1a_handle = dlopen("libBus1a.dylib", RTLD_LOCAL);
if (Bus1a_handle) {
char* (*b1a_name)() = dlsym(Bus1a_handle, "B1a_name");
if (b1a_name) {
printf("[%s] libBus1a.B1a_name() = %s\n",
__FILE__, b1a_name());
}
}
else {
printf("[%s] Unable to open libBus1a.dylib: %s\n",
__FILE__, dlerror());
}
dlclose(Bus1a_handle);
}
As a side note I came across this which neatly crystallises exactly the relationship between a dylib and a framework
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/loading_code.html#//apple_ref/doc/uid/TP40001830
>
> Thanks again and sorry for asking this sort of think so late at the weekend!
>
> Regards
>
> Jonathan Mitchell
>
> Developer
> Mugginsoft LLP
> http://www.mugginsoft.com
>
>
>
>
>
>
>
> On 8 Aug 2010, at 00:12, Alexander v. Below wrote:
>
>> I am using a library in a similar fashion (I am loading a jnilib in a Cocoa App), and I am calling dlsym to resolve the individual function addresses.
>>
>> Alex
>>
>> Am 08.08.2010 um 00:48 schrieb email@hidden:
>>
>>>
>>> My Cocoa app would very much like to link to a third party dylib.
>>>
>>> The dylib is created using an external make file and I don't really want to start modifying the build script to change the deployment INSTALL_PATH.
>>>
>>> I know that I can wield install_name_tool in a build phase but I thought about using dlopen().
>>> I know where my dylib is in my bundle so I can target it okay.
>>>
>>> 1. In Xcode I link to my dylib and mark it as weak.
>>> 2. In my app I call dlopen() before accessing any of the library symbols.
>>>
>>> But the symbol doesn't get resolved.
>>>
>>> The crash log reports:
>>>
>>> Dyld Error Message:
>>> can't resolve symbol _G__main in /Nuzzle/And/Scratch/MacOS/Contents/boo because dependent dylib #5 could not be loaded
>>>
>>> Do I have to manually call dlsym() or am I missing a weak attribute somewhere?
>>>
>>> Or am I just lost in the weeds.
>>>
>>> some code:
>>>
>>> NSString *dylibPath = [path stringByAppendingPathComponent:@"lib/libCint.dylib"];
>>> const char *libPath = [dylibPath cStringUsingEncoding:NSUTF8StringEncoding];
>>> void *dl = dlopen(libPath, RTLD_NOW);
>>> const char *dlErr = dlerror();
>>> if (dlErr) {
>>> NSLog(@"dlerror() = %s", dlErr);
>>> } else {
>>> NSLog(@"dylib path is %s, dl = %p", libPath, dl);
>>> }
>>> G__main(0, NULL); // in libCint.dylib
>>>
>>> Regards
>>>
>>> Jonathan Mitchell
>>>
>>> Developer
>>> Mugginsoft LLP
>>> http://www.mugginsoft.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
_______________________________________________
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