Bug 244237 - lang/spidermonkey60: undeclared readline dependency
Summary: lang/spidermonkey60: undeclared readline dependency
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Tobias C. Berner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-20 02:29 UTC by John Hein
Modified: 2020-03-26 08:26 UTC (History)
1 user (show)

See Also:
tcberner: maintainer-feedback+


Attachments
[patch] optionize gnu readline (886 bytes, patch)
2020-02-25 00:22 UTC, John Hein
jcfyecrayz: maintainer-approval? (tcberner)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Hein 2020-02-20 02:29:08 UTC
====> Running Q/A tests (stage-qa)
Error: /usr/local/bin/js60 is linked to /usr/local/lib/libreadline.so.8 from devel/readline but it
 is not declared as a dependency
Warning: you need USES+=readline


FYI, if you manually remove readline (pkg delete -f readline), then configure fails [1]. We probably could use --disable-readline to avoid the readline dependency, but it's probably fine to just add USES=readline.


[1]
checking for readline in -lreadline... no
configure: error: No system readline library found.
DEBUG: <truncated - see config.log for full output>
DEBUG: int main() {
DEBUG:
DEBUG: ; return 0; }
DEBUG: configure:8746: /usr/bin/cc -std=gnu99 -shared -Wl,-z,defs -Wl,--gc-sections -pthread  -fstack-protector-strong  -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro  -o conftest -Wl
DEBUG: configure:8818: checking for readline in -lreadline
DEBUG: configure:8837: /usr/bin/cc -std=gnu99 -o conftest -O2 -pipe  -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -ffunction-sections -fdata-sections -fno-math-errno -pipe -Qunused-arguments -isystem /usr/local/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2  -pthread  -fstack-protector-strong  -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro  conftest.c -lreadline  -lm -L/usr/local/lib 1>&5
DEBUG: /usr/bin/ld: cannot find -lreadline
DEBUG: cc: error: linker command failed with exit code 1 (use -v to see invocation)
DEBUG: configure: failed program was:
DEBUG: #line 8826 "configure"
DEBUG: #include "confdefs.h"
DEBUG: /* Override any gcc2 internal prototype to avoid an error.  */
DEBUG: /* We use char because int might match the return type of a gcc2
DEBUG:     builtin and then its argument prototype would still apply.  */
DEBUG: char readline();
DEBUG:
DEBUG: int main() {
DEBUG: readline()
DEBUG: ; return 0; }
DEBUG: configure: error: No system readline library found.
ERROR: old-configure failed
+ echo '===>  Script "../firefox-60.9.0/js/src/configure" failed unexpectedly.'
Comment 1 John Hein 2020-02-25 00:22:17 UTC
Created attachment 211913 [details]
[patch] optionize gnu readline

The patch makes READLINE an option.  When off, it uses the bundled editline (see js/src/editline/README).  When on it depends on the readline port. [1]

When using the readline port, mark the port infected by GPL since it is linking with a GPLv3 library.  The bundled editline is a more MPL friendly zlib license.

Also appease portlint a bit (move USES).

QA tested with poudriere testport WITH=READLINE and WITHOUT=READLINE.

[1] Note: I tried forcing it to link with the devel/libedit it, port it does not seem to work (doesn't show prompt, doesn't take line editing keys like arrows and ctrl-p, etc.).  I don't know if the threaded nature of js has anything to do with it.  I tried to debug it a bit, but failed to find the root cause.  The bundled editline seems to work fine for basic line editing.
Comment 2 Tobias C. Berner freebsd_committer 2020-02-25 05:25:30 UTC
Hi there

Thanks for the patch and the report, I try to get to it by the weekend :)


mfg Tobias
Comment 3 John Hein 2020-03-26 08:26:08 UTC
I did not bump PORTREVISION in the patch, but I think that would be necessary since the default in the patch is now to build with the bundled editline instead of GPL'd readline, which would change the package.

By the way, some references to the GPL / MPL issue.

From the MPL FAQ:

https://www.mozilla.org/en-US/MPL/2.0/FAQ - particularly Q14.

Also this excerpt from the editline/README:

"The editline API is a compatible subset of the FSF readline API; if
you have readline installed and would like to link to that instead,
define JS_READLINE.  Note that the readline library is distributed
under the GPL, so any resulting binaries are not legally
distributable."

https://github.com/mozilla/gecko-dev/tree/master/js/src/editline/README

I don't think this statement is currently accurate (maybe it was the interpretation for MPL 1.1?).

But it seems clear that linking with GNU readline would currently require distribution under the terms of both readline's GPL and the MPL (2.0).

That's some of the background that led to the current patch behavior (default readlie off, & add GPLv3 if readline on).