Re: Lpeg load error: undefined symbol: lua

I run configure got this, but not understand

---

SRCDIR = .
PREFIX = /usr/local
EXEC_PREFIX = $(PREFIX)
BINDIR = $(EXEC_PREFIX)/bin
DOCPREFIX = $(PREFIX)/share/doc
MANPREFIX = $(PREFIX)/share/man
SHAREPREFIX = $(PREFIX)/share
CC = cc
CFLAGS = -pipe -O2 -ffunction-sections -fdata-sections -fPIE
LDFLAGS = -Wl,-z,now -Wl,-z,relro
CFLAGS_STD = -std=c99 -D_POSIX_C_SOURCE=200809L -U_XOPEN_SOURCE -D_XOPEN_SOURCE=700 -DNDEBUG -D_FORTIFY_SOURCE=2
LDFLAGS_STD = -lc
CFLAGS_AUTO = -fstack-protector-all
LDFLAGS_AUTO = -Wl,--gc-sections -pie
CFLAGS_DEBUG = -U_FORTIFY_SOURCE -UNDEBUG -O0 -g3 -ggdb -Wall -Wextra -pedantic -Wno-missing-field-initializers -Wno-unused-parameter
CONFIG_HELP = 1
CFLAGS_TERMKEY =
LDFLAGS_TERMKEY = -ltermkey
CONFIG_CURSES = 1
CFLAGS_CURSES =
LDFLAGS_CURSES = -lncursesw
REGEX_SRC = text-regex-tre.c
CONFIG_TRE = 1
CFLAGS_TRE =
LDFLAGS_TRE = -ltre
CONFIG_LUA = 1
CFLAGS_LUA = -DLUA_COMPAT_5_1 -DLUA_COMPAT_5_2 -DLUA_COMPAT_5_3 -DLUA_COMPAT_ALL
LDFLAGS_LUA = -llua -lm -ldl
CONFIG_LPEG = 0
CFLAGS_LPEG =
LDFLAGS_LPEG =
CONFIG_ACL = 1
CFLAGS_ACL =
LDFLAGS_ACL = -lacl
CONFIG_SELINUX = 0
CFLAGS_SELINUX =
LDFLAGS_SELINUX =
CFLAGS_LIBC = -DHAVE_MEMRCHR=1

Makefile:

LDFLAGS_STD ?= -lc

LDFLAGS_VIS = $(LDFLAGS_AUTO) $(LDFLAGS_TERMKEY) $(LDFLAGS_CURSES) $(LDFLAGS_ACL) \
$(LDFLAGS_SELINUX) $(LDFLAGS_TRE) $(LDFLAGS_LUA) $(LDFLAGS_LPEG) $(LDFLAGS_STD)

The full Makefile is here https://github.com/martanne/vis/blob/master/Makefile

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.