lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


On Wed, Mar 4, 2009 at 10:28 AM, Asko Kauppi <> 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:
> - 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 |
>> 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