Requesting external libraries when lua is used within host program

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Requesting external libraries when lua is used within host program

pierlu
Hello, first post to the list.

I became aware of Lua because Gnugk has a module which permits to use lua scripts as the logic for routing h.323 calls https://www.gnugk.org/gnugk-manual-6.html#ss6.16

I experimented a little bit and Lua scripts works ok within Gnugk except from when I try to load the luasql module to connect to a mysql database; in that case I get the following error  in Gnugk Logs "lua.cxx(129)   LUA Error in LUA script: error loading module 'luasql. /usr/local/lib/lua/5.3/luasql/mysql.so: undefined symbol: lua_settop"

Given that I don't have such an issue when I use the interpreter, I ended up thinking that that error is caused by mysql.so library being compiled as C while lua being compiled within GnuGk as C++ (what helped me with this was this page https://stackoverflow.com/questions/32491131/how-to-fix-this-error-i-get-while-attempting-to-execute-a-lua-file-via-c and realizing that lua headers in GnuGk are included as an extern "C" block, see https://github.com/willamowius/gnugk/blob/master/lua.cxx at line 31).

Is my reasoning correct? If so, is there a way of doing things so that I can directly use the external library within embedded lua? 

At the moment I am using os.execute from the "embedded" script to have the lua interpreter execute another lua script that connects to the db and reading the output of such script from a temp file.

Any suggestions? 

Thanks,
pierlu 









Reply | Threaded
Open this post in threaded view
|

Re: Requesting external libraries when lua is used within host program

Viacheslav Usov
On Tue, Mar 12, 2019 at 12:40 PM pierlu <[hidden email]> wrote:

> while lua being compiled within GnuGk as C++

Does that mean Lua is linked as a static library?

Then it is not surprising that a shared library that expects Lua as another shared library cannot be loaded. You need to rebuild Lua as a shared library. It might be easier to compile it wholly as C first, just to see if that fixes the problem. But since you are trying to use it in a C++ host, you will then probably need to compile it as C++, but with its API declared as extern "C".

Or you will just have to accept that you cannot load binary Lua libraries. You can instead link them to your application statically.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Requesting external libraries when lua is used within host program

Andrew Gierth
In reply to this post by pierlu
>>>>> "pierlu" == pierlu  <[hidden email]> writes:

 pierlu> Given that I don't have such an issue when I use the
 pierlu> interpreter, I ended up thinking that that error is caused by
 pierlu> mysql.so library being compiled as C while lua being compiled
 pierlu> within GnuGk as C++

Before jumping to conclusions you should check the obvious thing: are
you exporting the necessary symbols from the main program?

Here is how to check, on ELF systems at least:

1. First establish if lua is being linked in as a static library or a
dynamic one. You can do this by doing `ldd yourprog` and seeing if the
output mentions a liblua.so / liblua-5.3.so or similar.

If there is a dynamic linked liblua then the symbols are available to
loaded modules and you have to look elsewhere for the cause of the
error.

2. If lua was linked statically, check the output of `nm -D yourprog`
to see if it mentions all of the lua_* symbols (which should appear as
defined, with 'T' and not 'U'). If they do not appear, then the main
program was not compiled with -Wl,--export-dynamic or -Wl,-E to export
its symbols to dynamically loaded libraries. (You'll notice if you look
at the lua sources that the "lua" executable is built this way.)

If on the other hand you see in the nm -D output symbols that look like
the lua_* ones but with added nonsense appended to the end, _then_ you
have a C vs C++ compilation mismatch.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Requesting external libraries when lua is used within host program

pierlu
yes!
Following your suggestions and recompiling the application with -Wl,--export-dynamic solved the issue!
Thank you very much!
pierlu

On Tue, Mar 12, 2019 at 2:40 PM Andrew Gierth <[hidden email]> wrote:
>>>>> "pierlu" == pierlu  <[hidden email]> writes:

 pierlu> Given that I don't have such an issue when I use the
 pierlu> interpreter, I ended up thinking that that error is caused by
 pierlu> mysql.so library being compiled as C while lua being compiled
 pierlu> within GnuGk as C++

Before jumping to conclusions you should check the obvious thing: are
you exporting the necessary symbols from the main program?

Here is how to check, on ELF systems at least:

1. First establish if lua is being linked in as a static library or a
dynamic one. You can do this by doing `ldd yourprog` and seeing if the
output mentions a liblua.so / liblua-5.3.so or similar.

If there is a dynamic linked liblua then the symbols are available to
loaded modules and you have to look elsewhere for the cause of the
error.

2. If lua was linked statically, check the output of `nm -D yourprog`
to see if it mentions all of the lua_* symbols (which should appear as
defined, with 'T' and not 'U'). If they do not appear, then the main
program was not compiled with -Wl,--export-dynamic or -Wl,-E to export
its symbols to dynamically loaded libraries. (You'll notice if you look
at the lua sources that the "lua" executable is built this way.)

If on the other hand you see in the nm -D output symbols that look like
the lua_* ones but with added nonsense appended to the end, _then_ you
have a C vs C++ compilation mismatch.

--
Andrew.