On Oct 2, 2010, at 3:48 AM, Kurt Sutter wrote: > Yes, that is an option I have considered. But, if I understand this > correctly, it would mean resolving some hundred symbols through dlsym and > providing a glue function for each of them. Right?
I don't see the need for a glue function. You do have to resolve the symbols you use. It is pretty typical to use a table, and possibly a bit of macro magic, to do this with minimal fuss. > (One other option I have just discovered is to place a symlink file in ~/lib, > which seems to be in the search path of the dynamic library loader. Any > thoughts about this?) I think it's a terrible idea. Both this and the use of DYLD_* variables have the same problem, which is that they affect things other than just your code. The symlink in ~/lib will affect absolutely everything run by that user. The DYLD_* environment variables are at least limited to your app process and its children, but that can still have unanticipated knock-on effects. Suppose, for example, that some Python module invokes a system tool to do its work. Suppose further that, as an implementation detail, that system tool uses Python internally. Your DYLD_* variable has now changed the behavior of that system tool and that Python module, possibly breaking them. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
