http://buildd.debian-ports.org/fetch.php?pkg=elinks&arch=hurd-i386&ver=0.12%7Epre5-1&stamp=1247378205&file=log&as=raw
shows two unsightly errors, apparently triggered by TERM=unknown:
tput: unknown terminal "unknown"
/build/buildd/elinks-0.12~pre5/configure: line 25480: test: -ge: unary operator expected
Hide the first of them by redirecting to /dev/null,
and avoid the second one by substituting "0" if tput fails.
I'm not sure why `which tput` is used instead of plain tput,
but it doesn't seem to be causing any problems in practice.
(There are problems in theory if tput is not installed,
tput is found in a directory whose name contains spaces,
or tput is a shell function or builtin.)
(cherry picked from elinks-0.12 commit 4369b052ef)
Don't search for SpiderMonkey in hardcoded directories
(/usr /usr/local /opt/spidermonkey /opt/js), and don't support
--with-spidermonkey=DIR (which I think was documented in elinks-users
only). Instead, ask pkg-config for mozjs185 or mozilla-js.
Everyone who installed SpiderMonkey in an unusual place must set
PKG_CONFIG_PATH appropriately.
This commit also includes a few minor changes in the SpiderMonkey
section of the configure script:
* Update the SpiderMonkey version number in "checking" messages
from 1.5 RC3a to 1.8.5, which matches the actual checks.
* Wrap the option documentation with AS_HELP_STRING.
* Use the Autoconf-generated $with_spidermonkey variable directly,
instead of copying $withval.
* Quote the arguments of macros more consistently.
* Warn if SpiderMonkey was requested but not found.
Fix a minor bug introduced in commit
de45a1df516deee13fe002a0f71678a2ce46cd73 on 2005-07-21.
Before that, EL_CHECK_OPTIONAL_LIBRARY used to do this:
if test -n "$withval" && test "x$withval" != xno; then
AC_MSG_ERROR([$2 not found])
fi
It was then changed to look in "[$]WITHVAL_$1" rather than "$withval",
but the initial "x" was lost in that change. Restore it.
AC_CHECK_FILE runs target executable and dies when cross-compiling.
It's unnecessary when checking for files in build environment,
simple runtime check will do.
Signed-off-by: Sergey Kvachonok <ravenexp@gmail.com>
The first option specifies the directory of xulrunner includes, eg.
--with-xulrunner_includes=/usr/include/xulrunner
The second: compiler options to find library, eg.
--with-xulrunner_libs="-Wl,-R/usr/lib/xulrunner -L/usr/lib/xulrunner -lmozjs"
One can add eg.
CPPFLAGS="-I/usr/include/xulrunner" LDFLAGS="-L/usr/lib/xulrunner -Wl,-R/usr/lib/xulrunner"
to the ./configure
Before xulrunner wasn't found. Now it is possible.
Implement new heartbeat code to catch runaway execution of document
ECMAScript code. The old code uses JS_SetBranchCallback which is
deprecated in new versions of SpiderMonkey. The new code uses setitimer(2)
and the JS_SetOperationCallback and JS_TriggerOperationCallback interfaces,
introduced in SpiderMonkey 1.8.1. Compatibility with both the old
JS_SetBranchCallback and the new interfaces is maintained.
Avoid compilation error with GNUTLS 1.2.9:
/home/Kalle/src/elinks-0.12/src/network/ssl/ssl.c:258: error: implicit declaration of function ‘gnutls_priority_set_direct’
If the function is not available, use gnutls_set_default_priority instead.
Perhaps it'll work with bugzilla.novell.com, perhaps not.
In 0.13.GIT, the configure script sets disable_gnutls=yes if it
decides to use nss_compat_ossl. In recent elinks-0.12, the script
logs "explicitly disabled" if $disable_gnutls is set. Thus, merging
those together could have caused an incorrect claim to be logged.
Rearrange the logic to make it easier to extend to multiple libraries.
Code that deals with one library no longer needs to worry about each
alternative library separately. Instead just test and set the one
shared chosen_ssl_library variable.
While at it, get rid of openssl_withval, which merely mirrored the
with_openssl variable provided by Autoconf.
The configure script used to run libgnutls-config in order to find the
compiler and linker options needed for using GNUTLS, but GNUTLS 2.7
apparently doesn't ship that script any more. Use pkg-config instead.
GNUTLS 1.2.0 is the oldest version supported by ELinks, and that already
installs the gnutls.pc file required by pkg-config.
This commit also removes support for configure --with-gnutls=DIR.
The configure script used to look for libgnutls-config in DIR.
DIR thus had to be a directory where executable programs were installed,
and it's unlikely that gnutls.pc would be found there. So, any callers
that used this feature would have to be changed anyway, and they can as
well be changed to set the PKG_CONFIG_PATH environment variable instead.
Fix this error:
configure.in:1430: error: AC_SUBST: `[CONFIG_TRE]' is not a valid shell variable name
acinclude.m4:31: EL_LOG_CONFIG is expanded from...
configure.in:1430: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
Reported by witekfl.
This check used to be in src/elinks.h. Move it to configure.in so
that (1) the result can be logged and (2) ELinks won't even link with
TRE if wchar_t prevents its use.
Also, rename HAVE_TRE_REGEX_H to CONFIG_TRE, to reflect that it is not
always defined if the header exists.
The previous version could display its progress like this:
checking for TRE... checking for TRE in pkg-config... yes
checking for TRE header and library... yes
no
Omit the outer "checking for TRE..." and "no" (which was untrue
anyway), unless --without-tre causes the inner checks to be skipped.
elinks-lite in Debian does not depend on any libraries (except
gnutls). Including this option will allow elinks-lite to be built
without libtre dependency.
Conflicts:
src/session/session.c: Kept the elinks-0.13 version.
Bug 1077 did not occur in elinks-0.13 because
setup_session here calls render_document_frames
directly and that sets ses->doc_view->vs.
The AsciiDoc 7.1.2 configuration files included in the ELinks
source tree apparently aren't compatible with AsciiDoc 8.4.4:
[ASCIIDOC] doc/elinks.1.xml
FAILED: [listdef-bulleted] missing section: [listtags-None]
make[1]: *** [elinks.1.xml] Error 1
Fix this by including asciidoc.py from AsciiDoc 7.1.2 as well.
The build system now doesn't care at all whether the user has
installed some version of AsciiDoc or not.
