bugGNU nano - Bugs: bug #50447, nano 2.7.5 fails to build with...

 
 

bug #50447: nano 2.7.5 fails to build with musl due to missing support for REG_STARTEND

Submitted by:  anon ymous <altf2>
Submitted on:  Fri 03 Mar 2017 06:01:55 PM UTC  
 
Severity: 3 - NormalStatus: Fixed
Assigned to: Benno Schulenberg <bens>Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 02 Apr 2017 09:50:32 AM UTC, comment #17:

The use if gnulib was released in 2.8.0.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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.)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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.

Mike Frysinger <vapier>
Project Member
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.

anon ymous <altf2>
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.

Mike Frysinger <vapier>
Project Member
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.

anon ymous <altf2>
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.

Mike Frysinger <vapier>
Project Member
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.

anon ymous <altf2>
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.

Mike Frysinger <vapier>
Project Member
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

anon ymous <altf2>
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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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

anon ymous <altf2>
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.

Mike Frysinger <vapier>
Project Member
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.

anon ymous <altf2>
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.

Mike Frysinger <vapier>
Project Member
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

anon ymous <altf2>
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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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

anon ymous <altf2>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by vapier (Posted a comment)
  • -unavailable- added by bens (Posted a comment)
  • -unavailable- added by altf2 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 02 Apr 2017 09:50:32 AM UTCbensOpen/ClosedOpen=>Closed
      Summarynano 2.7.5 build fails w/musl due to missing support for REG_STARTEND=>nano 2.7.5 fails to build with musl due to missing support for REG_STARTEND
    Thu 16 Mar 2017 06:39:36 PM UTCbensOpen/ClosedClosed=>Open
    Sun 12 Mar 2017 09:31:04 PM UTCvapierStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Wed 08 Mar 2017 07:08:11 AM UTCvapierSeverity4 - Important=>3 - Normal
      StatusNone=>Ready For Test
    Tue 07 Mar 2017 11:36:31 PM UTCvapierSummaryregression: build of latest release 2.7.5 fails with musl libc=>nano 2.7.5 build fails w/musl due to missing support for REG_STARTEND
    Sun 05 Mar 2017 04:55:10 PM UTCbensSeverity3 - Normal=>4 - Important
      Assigned toNone=>bens

    Back to the top


    Powered by Savane 3.1-cleanup1