Re: Possible problem with default_converter and tables

On Sun, Feb 07, 2010 at 05:10:32AM -0600, Catherine West wrote:
> Okay, I figured it out.  Turns out the problem I was describing was
> way more fundamental... any parameter that was passed by lua into c++
> and was a table, was causing the gc to fail later.  Really had nothing
> to do with default_converter.
> 
> The problem was actually compilation related.  I'm compiling this on
> Mac OS X, and compiling a shared library (the default) seems to act a
> little funny.  I looked at the symbol table for the final shared
> library, and it included parts of the static lua library (I don't know
> if this is normal). 

It is if you link to a static Lua library. At least on my OSX install,
that's all I have.

> This, in the way I was compiling, would have resulted in duplicate
> symbols from liblua.a in my final binary.  I suspect that this was
> causing duplicate per-dylib static variables (or something) that were
> confusing lua itself.

AFAIK, this should just work. Can you reproduce this? I would be
interested in the command line you used to build the library and final
executable. Is it possible that luabind was inadvertently linked against
a different Lua library than your executable?

> One other thing... compiling the shared library variant of luabind in
> Mac OS X yields another irritating problem.  For example, the
> @executable_path dylib symbol is incorrect in the finaly
> libluabind.dylib, and you have to change it to
> ../Frameworks/libluabind.dylib with install_name_tool in order to
> build an app directory correctly.  (I'm not sure if this is fixable,
> or even an error.  I'm not an expert)

I'm not sure what I can do about this. What is executable_path set to?

> Might it be possible to set the default target for the darwin toolset
> to build the static version of luabind, or at least say something
> about it in the documentation?  The static version of the library
> seems to work great, and is dead simple.

Yes, that's certainly possible. I'd like to make sure we can't do
anything better before doing that though.

-- 
Daniel Wallin
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev