Re: info.plist with DYLD_LIBRARY_PATH = ~/test
Re: info.plist with DYLD_LIBRARY_PATH = ~/test
- Subject: Re: info.plist with DYLD_LIBRARY_PATH = ~/test
- From: Kurt Sutter <email@hidden>
- Date: Sat, 2 Oct 2010 12:10:09 +0200
On 2 Oct 2010, at 11:07, Ken Thomases wrote:
> 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.
Sorry to be obtuse, but it may be that I am overlooking something. Presently, we have calls such as
n = PyNumber_Float(obj)
s = PyString_AsString(obj)
I understand that I would need to generate #defines for all those names, such as PyNumber_Float to map them to some table. I would have to initialize that table in a big for loop that goes through another table containing the name of each function (e.g. "PyNumber_Float". The loop then looks each name up with dlsym and initializes the table.
Or can this be done more elegantly?
>
>
>> (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.
What I thought is to place a symfile named MyAppPythonLink into ~/lib. Then use the install_name_tool in a build phase of my Xcode project to rename the Python library that the app imports to MyAppPythonLink. So this would only affect the behavior of my app, but not of any other apps.
Regards
Kurt_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden