Re: dependent shared symbols on OSX in a module

["Wesley Smith" <wesley.hoke@...>]

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.

best,
wes


On Thu, Feb 14, 2008 at 10:18 PM, Matt Campbell <mattcampbell@pobox.com> 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
>  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
>