Sun 02 Apr 2017 09:50:32 AM UTC, comment #17:
The use if gnulib was released in 2.8.0.
|
Thu 16 Mar 2017 06:39:36 PM UTC, comment #16:
Thanks for confirming that you can now compile nano, altf2. Could you also verify that searching for a regex (for example for \b) works correctly?
(Keeping the bug open so that I can see it in my default view, until the next release.)
|
Sun 12 Mar 2017 09:31:04 PM UTC, comment #15:
it isn't just for REG_STARTEND. if you look at the series of commits landed, it allowed us to drop a lot of custom/buggy shim layers in nano, and become easier to port to more platforms (like Windows). it also keeps us from adding even more (which people were proposing), and it let's us continue to use newer features that are available in the GNU world but not elsewhere. i think you severely underestimate the burden of duplicating gnulib, or of disabling functionality when a platform is missing features.
(1) this is a non-issue for most people who get their builds from their distros.
(2) only if your C lib is buggy, or if nano is using features it doesn't provide. if you have concrete cases where gnulib is pulling in stuff nano doesn't actually need, then detail it in a bug. we've stubbed out a few features we know nano doesn't care about (like float support in printf).
since nano now builds for musl, there's nothing left to do here, so we can close out the bug. unless Benno wants to wait until the next actual release.
|
Sun 12 Mar 2017 03:38:00 PM UTC, comment #14:
ok, i can confirm it works now (missing xsize was due to a bug in the join impl i used). however i think having to use gnulib just for the sake of REG_STARTEND is a high price to pay:
1) build time is significantly longer due to all the configure tests run by gnulib and then the compilation of all of the gnulib replacements, and
2) size of the resulting binary will be significantly larger due to all the replicated libc functions (many of them are unnecessarily being pulled in, since gnulib uses the aforementioned assume-worst approach to building its replacements.
|
Wed 08 Mar 2017 08:51:21 PM UTC, comment #13:
considering your first run failed due to tool compatibility issues, try deleting the lib/ dir entirely and then run the gnulib-tool. if xsize still isn't pulled in to lib/, then you can try debugging that tool and figure out why.
if you don't want to debug gnulib and send them patches/bug reports, then find a GNU system to run `./autogen.sh` on first.
|
Wed 08 Mar 2017 07:20:56 PM UTC, comment #12:
there's nothing in the autogen.sh output talking about xsize, and it's not mentioned in the module list in autogen.sh.
to me looks like a bug where one module pulls in another, but does not update the dependencies accordingly.
|
Wed 08 Mar 2017 07:17:23 PM UTC, comment #11:
xsize is a gnulib module. it should be created as part of the ./autogen.sh step. if it wasn't, go back and look at the output of gnulib and see where it's going wrong.
|
Wed 08 Mar 2017 07:07:59 PM UTC, comment #10:
xsize.h is in the gnulib/ dir (git checkout), but not in the lib/ dir make enters.
|
Wed 08 Mar 2017 07:00:15 PM UTC, comment #9:
xsize is a gnulib module. it should be created as part of the ./autogen.sh step. if it wasn't, go back and look at the output of gnulib and see where it's going wrong.
|
Wed 08 Mar 2017 06:22:13 PM UTC, comment #8:
thanks. that alone didn't work, i also had to change doc/Makefile.
now i get this error:
gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall -MT printf-parse.o -MD -MP -MF $depbase.Tpo -c -o printf-parse.o printf-parse.c &&\
mv -f $depbase.Tpo $depbase.Po
printf-parse.c:72:19: fatal error: xsize.h: No such file or directory
#include "xsize.h"
^
compilation terminated.
make[4]: *** [printf-parse.o] Error 1
|
Wed 08 Mar 2017 03:24:36 PM UTC, comment #7:
Yes, when building from git, you need texinfo installed -- see README.GIT. If you don't want to bother with that, just touch doc/nano.html and carry on.
|
Wed 08 Mar 2017 03:02:48 PM UTC, comment #6:
i installed another join tool and got it to run through.
now the build fails when running make:
$ make -j2
make all-recursive
make[1]: Entering directory `/home/user/nano'
Making all in doc
make[2]: Entering directory `/home/user/nano/doc'
rm -rf nano.htp
if /bin/bash /home/user/nano/missing makeinfo --html --no-split -I . \
-o nano.htp nano.texi; \
then \
rm -rf nano.html && mv nano.htp nano.html; \
else \
rm -rf nano.htp; exit 1; \
fi
/home/usernano/missing: line 81: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
You should only need it if you modified a '.texi' file, or
any other file indirectly affecting the aspect of the manual.
You might want to install the Texinfo package:
<http://www.gnu.org/software/texinfo/>
The spurious makeinfo call might also be the consequence of
using a buggy 'make' (AIX, DU, IRIX), in which case you might
want to install GNU make:
<http://www.gnu.org/software/make/>
make[2]: *** [nano.html] Error 1
|
Wed 08 Mar 2017 07:08:11 AM UTC, comment #5:
please report your troubles to the upstream gnulib list instead. nano isn't the support point for issues with it.
|
Wed 08 Mar 2017 05:42:48 AM UTC, comment #4:
i tried to build from git, however when i run autogen.sh gnulib-tool goes into an infinite loop:
join: usage: join [-1 x -2 y] [-o list] file1 file2
Module list with included dependencies (indented):
getdelim
getline
getopt-gnu
glob
isblank
iswblank
lstat
regex
sigaction
snprintf-posix
stdarg
strcase
strcasestr-simple
strnlen
sys_wait
vsnprintf-posix
wchar
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
wctype-h
... etc ...
it seems the super-portable portability library makes non-portable assumptions at least about the "join" utility.
my join utility is from 9base, for the record, and i've never had a problem with it so far.
|
Tue 07 Mar 2017 11:35:47 PM UTC, comment #3:
if you have porting problems with gnulib, then report them to gnulib and get them fixed. a large number of projects (both in GNU and beyond) rely on gnulib as its porting layer. expecting every project out there to implement their own OS shims/compat layers is unreasonable. the end result is going to be even worse than gnulib in terms of bugs and waste of developer time.
please retest with current nano git master and see if the regex issue is resolved.
|
Tue 07 Mar 2017 06:09:21 AM UTC, comment #2:
glad to hear you're willing to fix it, however i doubt that gnulib is a good solution: https://gitlab.com/sortix/sortix/wikis/Gnulib
i can tell you that i also had my share of 'Fun' with gnulib; when i started making a distro based on musl libc 6 years ago, gnulib was the major offender:
http://wiki.musl-libc.org/wiki/FAQ#Q:_I.27m_getting_this_gnulib_error
it was a huge effort to patch around gnulib at that time, and it had to be done for every single package using it differently, since all of them used a different set of functions and different versions. apart from that, it often defaults to "assume broken", for example on crosscompilation when it cannot execute some tests.
in that case you also get a bloated (static linked) binary, since some functions are linked in twice. i.e. libc's version of a function that may be used internally, and then the copy of gnulib.
https://github.com/sabotage-linux/sabotage/commit/e256f9dfe75de7da8d9d1290fb95dcba900a1fdd
|
Sun 05 Mar 2017 04:55:10 PM UTC, comment #1:
Thanks for reporting. I was curious whether there would be any systems that don't support REG_STARTEND. :)
The next release (less than a month away) will start using gnulib, so then this regression should go away.
|
Fri 03 Mar 2017 06:01:55 PM UTC, original submission:
utils.c: In function 'strstrwrapper':
utils.c:356:6: error: 'REG_STARTEND' undeclared (first use in this function)
REG_STARTEND) != 0)
musl libc does not support REG_STARTEND, since it's not POSIX.
so that breaks build on alpine linux, which is quite trendy now.
http://www.openwall.com/lists/musl/2016/10/04/11
|