I suspect that elinks lua support is quite old and won't work with lua later than 5.0 (which is gone from ports).
It builds, but configure fails, so lua is turned off.
'make configure' with the LUA option on produces:
checking for Lua... no
And in config.log...
configure:17581: checking for Lua
configure:17640: cc -o conftest -O2 -pipe -I/usr/local/include/nspr -I/usr/local/include/js-1.7 -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -Wall -I/usr/local/include/lua51 -isystem /usr/local/include -L/usr/local/lib -lnspr4 -pthread -lpthread -lm -Wl,-rpath,/usr/local/lib -fstack-protector -rdynamic conftest.c -llua -llualib -lm -ljs -lexecinfo -L/usr/local/lib -lbz2 -lexpat >&5
conftest.c:145:17: warning: implicit declaration of function 'luaL_newstate' is invalid in C99 [-Wimplicit-function-declaration]
lua_State *L = lua_open();
/usr/local/include/lua51/lua.h:287:20: note: expanded from macro 'lua_open'
#define lua_open() luaL_newstate()
conftest.c:145:13: warning: incompatible integer to pointer conversion initializing 'lua_State *' (aka 'struct lua_State *') with an expression of type 'int' [-Wint-conversion]
lua_State *L = lua_open();
2 warnings generated.
/usr/bin/ld: cannot find -llua
And in config.h:
/* Define if you want: Lua support */
/* #undef CONFIG_LUA */
Just fixing the compilation args used for the configure test to work with lua51 (for example) is not enough. The resulting test program seg faults (lua_open produces something luaopen_base() does not like).
Unless someone wants to do surgery to update elinks to work with newer lua (and submit upstream ideally), I suggest we just remove the option and pass --without-lua to configure.
A commit in branch main references this bug:
Author: Alexey Dokuchaev <danfe@FreeBSD.org>
AuthorDate: 2022-06-14 09:40:36 +0000
Commit: Alexey Dokuchaev <danfe@FreeBSD.org>
CommitDate: 2022-06-14 09:40:36 +0000
www/elinks: fix handing of several non-default options
- Depend on the correct Guile 3.x library name
- Prefer our default Lua version and pass it to the configure
script the way it expects (*)
- Add `pkgconfig' to the global USES list since it is commonly
used during configure, and limit `localbase' to the only
option that actually needs it (IDN)
- Drop no longer useful `--with-expat' and redundant `-pthread'
PR: 226878 (*)
www/elinks/Makefile | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
(In reply to commit-hook from comment #2)
'make build' now fails if spidermonkey78 is installed
gmake: Entering directory '/wrkdirs/usr/ports/www/elinks/work/elinks-0.15.0/src/dialogs'
cc -DHAVE_CONFIG_H -I../.. -I../.././src -O2 -pipe -I/usr/local/include/nspr -I/usr/local/include/js-1.7 -fstack-protector-strong -fno-strict-aliasing -Wall -fpermissive -include /usr/local/include/mozjs-78/js/RequiredDefines.h -isystem /usr/local/include/mozjs-78 -I/usr/local/include/nspr -fno-strict-aliasing -Wno-array-bounds -Wno-address -fno-strict-overflow -o info.o -c info.c
In file included from info.c:22:
In file included from ../.././src/ecmascript/ecmascript.h:13:
In file included from /usr/local/include/js-1.7/jsapi.h:47:
In file included from /usr/local/include/js-1.7/jspubtd.h:45:
/usr/local/include/js-1.7/jstypes.h:248:6: error: "Must define one of XP_BEOS, XP_OS2, XP_WIN or XP_UNIX"
# error "Must define one of XP_BEOS, XP_OS2, XP_WIN or XP_UNIX"
/usr/local/include/js-1.7/jstypes.h:264:2: error: No suitable type for JSInt8/JSUint8
#error No suitable type for JSInt8/JSUint8
/usr/local/include/js-1.7/jstypes.h:277:2: error: No suitable type for JSInt16/JSUint16
#error No suitable type for JSInt16/JSUint16
/usr/local/include/js-1.7/jstypes.h:297:2: error: No suitable type for JSInt32/JSUint32
#error No suitable type for JSInt32/JSUint32
The elinks configure.ac looks for mozjs-78.pc, so it seems like it should build with spidermonkey78. It may be that moving toward building with that instead of the old spidermonkey17 might be an option. That seems like that (spidermonkey78) pulls in a dependency on sqlite3 and libxml++-5.0 (the latter is not in the current ports tree yet, so that addition may be needed to build with spidermonkey78). Without those dependencies installed the configure steps to check for spidermonkey fail, so support for spidermonkey is disabled.
(In reply to John Hein)
> 'make build' now fails if spidermonkey78 is installed
That's one problem...
> The elinks configure.ac looks for mozjs-78.pc, [or would the] check for
> spidermonkey fail, so support for spidermonkey is disabled [regardless of
> the enabled option]
And that's the other, indeed: "checking for SpiderMonkey (mozjs-78) in pkg-config mozjs-78... no". My bad, how could I've missed that! I'll see what I can do.
(In reply to Alexey Dokuchaev from comment #5)
Rather than clutter this bug further, I opened a new one: bug 264700