site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) -----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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com