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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  anon ymous <altf2>
Submitted:  Fri 03 Mar 2017 06:01:55 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

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>
Group administrator
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>
Group administrator
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator
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>
Group 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>
Group 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>
Group administrator
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.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-04-02 bens Open/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
    2017-03-16 bens Open/ClosedClosed Open
    2017-03-12 vapier StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-03-08 vapier Severity4 - Important 3 - Normal
        StatusNone Ready For Test
    2017-03-07 vapier Summaryregression: 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
    2017-03-05 bens Severity3 - Normal 4 - Important
        Assigned toNone bens

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code