Bug 226878 - www/elinks: lua support does not work
Summary: www/elinks: lua support does not work
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Alexey Dokuchaev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-23 18:15 UTC by John Hein
Modified: 2022-06-16 00:33 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (beat)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Hein 2018-03-23 18:15:30 UTC
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.
Comment 1 Walter Schwarzenfeld freebsd_triage 2020-01-31 18:14:00 UTC
Ping!
Comment 2 commit-hook freebsd_committer 2022-06-14 09:42:28 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=93992337df3df24e2fb7788a3157a885ffc4b408

commit 93992337df3df24e2fb7788a3157a885ffc4b408
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(-)
Comment 3 John Hein 2022-06-14 18:42:35 UTC
(In reply to commit-hook from comment #2)
'make build' now fails if spidermonkey78 is installed


gmake[3]: 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
 .
 .
 .
Comment 4 John Hein 2022-06-14 19:08:16 UTC
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.
Comment 5 Alexey Dokuchaev freebsd_committer 2022-06-15 03:24:29 UTC
(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.
Comment 6 John Hein 2022-06-16 00:31:47 UTC
(In reply to Alexey Dokuchaev from comment #5)
Rather than clutter this bug further, I opened a new one: bug 264700