lua-users home
lua-l archive

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


I install Lua by this

    && curl -R -O http://www.lua.org/ftp/lua-5.4.1.tar.gz \
    && tar zxf lua-5.4.1.tar.gz \
    && cd lua-5.4.1 \
    && make MYCFLAGS="-fPIC" linux \
    && make install \

But if I add liblua.so in Makefile of Lua as TO_LIB= liblua.a liblua.so got:

install: cannot stat 'liblua.so': No such file or directory
make: *** [install] Error 1

On Mon, Dec 7, 2020 at 5:45 PM Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "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.


--
______________________________________
http://richiewu.is-programmer.com
Ricky J. Ng