lua-users home
lua-l archive

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


	Hi Thomas

Ok, so I then pull the latest luasql source, and examining the make it
appears to want compat-5.1.  So I pull that also, and after messing with
the config directories a bit, get it to compile.  I also run 'make
install' after editing the config thusly (attempting to use lua 5.1):
	Today I've just upgraded some drivers with Lua 5.0 and 5.1
compatibility (but only Postgres was tested).

compat is needed to use lua50 with the behavior of lua51. compat is not
to be used with lua51.

If I edit the luasql Makefile to remove the compat-5.1 object file from OBJS, and rebuild, I get the following runtime error when executing the test.lua under lua 5.1.1:
	Did you removed the `#include "compat-5.1.h"' from *.c ?

lua: error loading module 'luasql.mysql' from file '/usr/local/lib/lua/5.1/luasql/mysql.so':
       /usr/local/lib/lua/5.1/luasql/mysql.so: undefined symbol: luaL_module
stack traceback:
       [C]: ?
       [C]: in function 'require'
       test.lua:599: in main chunk
       [C]: ?
	I think luaL_module only exists in compat-5.1.c...

I'm guessing that the undefined symbol is defined in the 5.1 version of liblua, and it is not in 5.0 (but is provided via the compat-5.1 library).
	I think you're mixing Lua 5.0 with Lua 5.1 binaries, which
might not work...

When I run lua as above, I am running the 5.1.1 version I built - and it was statically linked to liblua.a. I don't really understand how mysql.so is meant to dynmically link to whatever library contains luaL_module - how is that library specified? The makefile only gives a LIB_OPTION of "-shared". It doesn't specify liblua.so, for example, anywhere.
	It doesn't specify liblua.so because the symbol could be exported
by other file, as lhf pointed out (the executable, for instance).

A further source of confusion to my win32 trained brain: why is the undefined symbol not caught at compile time?
	If this is an external symbol which could not be found at runtime,
how could the compile caught an error?

Is there no equivalent of "import libraries" that one can link against to ensure symbols we're expecting to find in a shared library are in fact available? (and that tell us which shared libraries to load on execution)
	I think the dynamic libraries model is rather different?

Finally, what tool can I use to look at which shared libraries a program has opened (and where they were loaded from?)
	You could check for dynamic libraries statically linked to
an executable or to a library with `ldd <complete-path-to-my-file>[.so]'.
But this could not solve the problem (LuaSQL drivers usually are statically
linked to the database client library but not to Lua).

	For now, I recommend one of two choices:

- use Lua 5.0 with Compat-5.1 R5: this is the safety choice :-)
- use Lua 5.1 (without Compat!) with the CVS HEAD: this was not tested!

	Hope this long letter will help you
		Tomas