[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: OSX and loadlib
- From: Wesley Smith <wesley.hoke@...>
- Date: Wed, 4 Mar 2009 13:23:27 -0800
Actually dlopen is not ideal on OSX. It wreaks havoc with
CoreAudio/CoreMidi type frameworks whereas NSLoadModule functions
behave appropriately. From what I remember reading the tech docs,
they highly recommended NSLoadModule over dlopen and from my
experience this is sage advice.
wes
On Wed, Mar 4, 2009 at 10:28 AM, Asko Kauppi <askok@dnainternet.net> wrote:
>
> I believe the last concensus was to get rid of DYLIB altogether. There were
> reasons why use of dlopen is better, now that recent OS X supports it.
>
> If you're able to change it, do. :)
>
> Archive keys:
> http://lua-users.org/lists/lua-l/2007-04/msg00061.html
> http://lua-users.org/cgi-bin/namazu.cgi?query=NSLINKMODULE_OPTION_PRIVATE&idxname=lua-l&max=20&result=normal&sort=score
>
> - asko
>
>
> Wesley Smith kirjoitti 4.3.2009 kello 19:59:
> - Show quoted text -
>
>> Hi list,
>> In a current project, I need to be able to grab symbols from a loaded
>> C module like static functions etc., but I don't want to have to
>> provide a reference to the module in question as having to keep track
>> of structures (on OSX) like NSModule will be clumsy. Looking at
>> loadlib.c, there's this line:
>>
>>
>> NSModule mod = NSLinkModule(img, path, NSLINKMODULE_OPTION_PRIVATE |
>> NSLINKMODULE_OPTION_RETURN_ON_ERROR);
>>
>>
>> Is there a reason for the NSLINKMODULE_OPTION_PRIVATE flag? I realize
>> it keeps the module from polluting the globals table, but for my
>> purposes this prevents me from having the symbols in question readily
>> available. I'm wondering what issues there would be in removing this
>> flag. In what tech notes I found on the subject I didn't see any
>> gotchas, but there's probably something lurking there. If removing
>> this flag isn't an option, would it be possible to have a config
>> option to say "yes, I want C module symbols in the globals table"?
>>
>> The reason I need this behavior is I'm using LLVM to generate
>> functions etc. form within Lua scripts and I want to be able to hook
>> in to functions defined in C modules without necessarily having to
>> build a shared lib and a lua module for each case where I want this
>> behavior.
>>
>> thanks,
>> wes
>
>