 |
lua-l archive |
|
|
||
|
>>>>> "Ricky" == Ricky Wu <rickywu1113@gmail.com> writes:
Ricky> Yes, vis this the executable,
Ricky> Here are the output
Ricky> nm -D vis:
[snip long list that includes no lua_* symbols]
Ricky> [root@2f8f62323694 /]# ldd /usr/local/bin/vis
Ricky> linux-vdso.so.1 => (0x00007ffe03f4d000)
Ricky> libtermkey.so.1 => /lib64/libtermkey.so.1 (0x00007f23c3eea000)
Ricky> libncursesw.so.5 => /lib64/libncursesw.so.5 (0x00007f23c3cb2000)
Ricky> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f23c3a88000)
Ricky> libacl.so.1 => /lib64/libacl.so.1 (0x00007f23c387f000)
Ricky> libtre.so.5 => /lib64/libtre.so.5 (0x00007f23c366f000)
Ricky> libm.so.6 => /lib64/libm.so.6 (0x00007f23c336d000)
Ricky> libdl.so.2 => /lib64/libdl.so.2 (0x00007f23c3169000)
Ricky> libc.so.6 => /lib64/libc.so.6 (0x00007f23c2d9b000)
Ricky> libunibilium.so.4 => /lib64/libunibilium.so.4 (0x00007f23c2b88000)
Ricky> libattr.so.1 => /lib64/libattr.so.1 (0x00007f23c2983000)
Ricky> /lib64/ld-linux-x86-64.so.2 (0x00007f23c437e000)
OK, so vis isn't linked against a dynamic liblua.so, therefore it must
either have been linked against a static liblua without exporting the
lua symbols, or it is loading a liblua.so via dlopen and not using
RTLD_GLOBAL. Neither of those approaches will allow dynamic loading of
lua modules, which will fail with undefined symbol errors.
You didn't tell us what command had been used to link the vis binary.
One strong possibility is that vis is expecting the presence of a
liblua.so but for whatever reason you don't have one, but only a
liblua.a, which would not cause an error when linking vis but would
result in exactly this failure at runtime.
--
Andrew.