Indeed, I'm aware of the incompatibility with Windows here. I prefer
this case it's not. The offending symbol is
whatever reason. It would be really nice to know why. I had a hell
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.
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
libraries.
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 libmymatrix.so, 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 libmymatrix.so. (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.)
Matt
