Re: Problem with dlsym
Re: Problem with dlsym
- Subject: Re: Problem with dlsym
- From: "Peter O'Gorman" <email@hidden>
- Date: Fri, 13 May 2005 08:20:37 +0900
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
J. Davison de St. Germain wrote:
| We have been using the 'dlcompat' library on OSX for a while and it
| worked great. However, with Tiger 10.4, it appears that the dl
| functions (eg: dlsym) are now built in. Unfortunately, when we try to
| find a non-existent symbol in one of our large shared libraries, it
| now takes forever (instead of returning null fairly
| quickly/immediately). After about 20 minutes of 'working' on the
| dlsym call, our program will return and say that it couldn't find the
| symbol. When we used dlcompat before, we didn't have this problem.
| We have read the man page and tried all the different options that are
| presented, but nothing seems to help.
As an alternative to Jordan's suggestion, change calls to dlsym to:
if (NSIsSymbolNameDefined(sym)) dlsym(handle,symbol);
Another alternative, very hacky, works because of an implementation detail
that may change, change calls to dlsym to use NSLookupSymbolInModule():
void* my_dlsym(void* module,const char* symbol) {
~ char* u_sym=NULL;
~ void* address=NULL;
~ int retCode= asprintf(&u_sym,"_%s",symbol); // ignoring error, naughty!
~ address=NSAddressOfSymbol(NSLookupSymbolInModule(handle,u_sym));
~ free(u_sym);
~ return address;
}
|
| (Note, if we try the same lookup of a non-existent symbol on a
| system library, it returns very quickly. The library that we are
| searching is part of a large framework of other libraries and (apparently)
| for some reason loads all of the other libraries in its search for the
| symbol. This does seem strange as we specify the exact dylib that we
| want to searh through.)
This is correct behavior. Well, correct except for the fact that it takes
forever :). The specification for dlsym states that it will look for the
symbol in objects loaded as a result of loading the object specified by
handle. dlcompat also does this, but only checks one level deep (bad!) so
does not get into a loop for circular dylibs.
|
| In a last ditch effort, we tried compiling and using the original
| 'dlcompat' libraries.
Yeah, this is unlikely to work.
I am not convinced that the bug requires circularity. Do you have any
circular dependencies in your framework? This was also noticed by fink's kde
maintainer, kde startup times went > 24 hours with tiger, but I did not see
any obvious circularity in the libraries. Haven't had a chance to look
closely. Perhaps your setup is easier to make a smallish test case?
Peter
- --
Peter O'Gorman - http://www.pogma.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQoPkxbiDAg3OZTLPAQJx2AP6Aqfu6C9wfkvnxNMZ1PPhjWssmD4KonnD
jDLRw3YnbEYaGDlA1X7Llyna8OMat+RpQewo5MAsLi/wX2xRmeh2kJgDIypsMtJb
v3+zmjizJQVJm7m+0rARApF50PkEXRIJrPz2WysSckAcVOEflZGL+JtsWZflCEZ8
vYWFI+bDCLA=
=nFSB
-----END PGP SIGNATURE-----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden