lua-users home
lua-l archive

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

In this case, couldn't you retrieve the static variable via a call through Lua? 

This could be via the C API, e.g pushing the static variable as a lightuserdata into LUA_REGISTRYINDEX.  If you know that is loaded, then you can retrieve this pointer safely, no matter whether the symbol is global (in the C library sense) or not.

On Feb 14, 2008, at 10:24 PM, Wesley Smith wrote:

Indeed, I'm aware of the incompatibility with Windows here.  I prefer
to avoid building extra shared libs where possible, but it seems in
this case it's not.  The offending symbol is

static const char * Matrix_udata::name

It seems that data symbols don't export as well as text symbols for
whatever reason.  It would be really nice to know why.  I had a hell
of a time exporting data symbols from dlls on windows but was lucky
enough to see how to do it a few days before in the OpenEXR code.
Thanks for the suggestions.  I was actually in the process of building
a shared Framework.


On Thu, Feb 14, 2008 at 10:18 PM, Matt Campbell <> wrote:
In my opinion, the best solution is to only export the luaopen_*
 function from the .so or .dll file for a Lua C module.  All other shared
 symbols should be in a plain C library or multiple C libraries, and all
 modules which require those symbols should link against said library or

 In your case, the symbols from the matrix module which are used by the
 image module would be moved to a shared library, which I'll call
 "mymatrix" for the sake of this explanation.  On OS X and other
 Unix-like systems, you'd have a .so file called, which
 would be installed in the standard location for shared libraries or some
 other directory on the dynamic linker's search path, and both the image
 and matrix Lua C modules would link against (I maintain
 that even on ELF-based systems, shared libraries should always link
 against their dependencies instead of assuming that the executable will
 load them.) On Windows, the shared symbols would be located in a DLL
 called mymatrix.dll, which would be located somewhere in the user's PATH
 or in the same directory as the EXE, and the image and matrix Lua C
 modules would link against this DLL.

 I think this approach is the most portable and reliable. (I mention
 portability because what you're currently trying to do assumes that the
 process has a global symbol table, which isn't the case on Windows.)


Be seeing you

grrr waaa