Sun 02 Apr 2017 03:45:56 PM UTC, original submission:
TL;DR: it seems that if configure decides to use the internal regex implementation, the following wordbounds conftest fails due to using the replacement symbols (rpl_regcomp etc) without including their implementation.
The long version:
With nano 2.8.0 on Alpine linux (which uses musl-libc), the user-visible symptom is a lot of errors similar to the following while nano tries to load color syntax files:
Error in /usr/share/nano/c.nanorc on line 7: Bad regex "[[:<:]][A-Z_][0-9A-Z_]+[[:>:]]": Invalid character class name
When building locally from nano-2.8.0.tar.gz (where the resulting nano has the same symptoms), configure shows:
"checking for GNU-style word boundary regex support... no"
And so decides to fallback to [[:<:]] boundary chars - which apparently are not recognized at runtime, and so those errors appear.
Checking the wordbounds conftest at config.log, it fails with the following:
<path>/nano-2.8.0/conftest.c:533: undefined reference to `rpl_regcomp'
<path>/nano-2.8.0/conftest.c:535: undefined reference to `rpl_regexec'
The replacements "#define regcomp rpl_regcomp" and similar ones are used at the wordbounds conftest file because previously configure determined that it needs to use its own regex implementation. Previously at config.log:
configure:24290: checking for working re_compile_pattern
...
configure:24510: result: no
Going back to the wordbounds conftest, it's invoked like so:
configure:34072: checking for GNU-style word boundary regex support
configure:34120: gcc -o conftest -g -O2 -Wall conftest.c -lncursesw >&5
Which, as far as I can tell, does not make use of the internal regex sources or obj files, and hence fails to find the implementation of rpl_regcomp etc.
I think the solution should be that if configure decides to use the internal regex implementation, then it should not test for GNU-style word boundary regex and instead answer "yes" automatically (assuming the internal implementation does support it, which is most probably "yes").
As a workaround until a fix arrives, on systems where configure decides to use the internal regex implementation, one could invoke "./configure --with-wordbounds" which tells configure it's supported without actually testing it, and the resulting binary indeed loads the syntax files correctly.
|