bugGNU nano - Bugs: bug #62124, gnulib build failure on...

 
 

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

bug #62124: gnulib build failure on Cygwin+Android NDK for nano 6.1 and 6.2

Submitter:  Chris Renshaw <osm0sis>
Submitted:  Mon 28 Feb 2022 03:02:07 AM UTC
   
 
Severity:  3 - Normal Status:  None
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Thu 10 Nov 2022 08:23:38 AM UTC, comment #15: 

You're welcome.  Thanks for following up.

Benno Schulenberg <bens>
Group administrator
Thu 10 Nov 2022 01:57:29 AM UTC, comment #14: 

Sorry for taking so long to reply, I had a SSD failure and it's taken this long to get things up and running again.

Paul's suggestion:

SHELLOPTS='igncr'

doesn't work, but:

export SHELLOPTS
set -o igncr

does.

Setting these can break other things in Cygwin, however, which is why they aren't the default. My solution would have sanitized things to work with the default env everywhere, including Cygwin.

Oh well, I've moved on to WSL2 on my new laptop, so I won't bother pushing this any further, beyond maybe a reply with the above.

Thanks for your time Benno!


Chris Renshaw <osm0sis>
Mon 25 Apr 2022 09:12:48 AM UTC, comment #13: 

Have you tried Paul's suggestion, setting SHELLOPTS='igncr' in your environment?

Benno Schulenberg <bens>
Group administrator
Sun 24 Apr 2022 12:13:34 PM UTC, comment #12: 

The new reply got disconnected from my previous thread on the gnulib list for some reason, so here's the new thread with my submitted patch:

https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00000.html

Sounds like Paul doesn't want to accept it however, though the Windows Android NDK will always output CRs whether in Cygwin or not.

I'll try once more to explain that, but if it seems like he's still ignoring my information then I won't pursue it further.

Chris Renshaw <osm0sis>
Fri 01 Apr 2022 12:18:50 AM UTC, comment #11: 

Hey, thanks again for following up.

I've managed to fix it locally, just haven't had time to submit a patch.

Basically you were right about the lone " - " before the new "-Wno-unsuffixed-float-constants" being suspect, which it turns out was an option added by the breaking commit.

In the Makefile creation, when the compiler output is parsing, all of the -W options from that commit end up on their own lines in my setup because the Windows NDK CC is outputting LF+CR line endings, making it look like this:

GL_CFLAG_GNULIB_WARNINGS = 
 -Wno-cast-qual
 -Wno-conversion
 -Wno-float-equal
 -Wimplicit-fallthrough
 -Wno-sign-compare
 -Wno-undef
 -Wno-unused-function
 -Wno-unused-parameter
 
 
 -Wno-float-conversion
 
 
 -Wno-pedantic
 
 
 -Wno-sign-conversion
 -Wno-type-limits
 
 
 -Wno-unsuffixed-float-constants

So the solution is to strip all the CRs out so that the `for word in` loop can read them correctly and append them to a single line variable for GL_CFLAG_GNULIB_WARNINGS.

My change, tested and working, was

gnulib/m4/gnulib-common.m4:
-      gl_options=`grep -v '#' conftest.out`
+      gl_options=`grep -v '#' conftest.out | tr -d '\r'`

My plan is to submit it as a patch to the mailinglist over the weekend if I can find some time between child care wake/feeding windows. :P

Chris Renshaw <osm0sis>
Thu 31 Mar 2022 10:37:40 AM UTC, comment #10: 

(Upstream report was made at https://lists.gnu.org/archive/html/bug-gnulib/2022-03/msg00054.html.  Thanks.)

If in the lib/Makefile you simply delete the newly added '-Wno-unsuffixed-float-constants', does compilation then succeed?

Benno Schulenberg <bens>
Group administrator
Thu 17 Mar 2022 03:26:51 PM UTC, comment #9: 

There's no need to dig into mailing list stuff -- just send your report to bug-gnulib@gnu.org.  There is no need to subscribe -- it will take some hours before a moderator will let it pass and it will appear in the archives.  Thanks for bisecting.

Benno Schulenberg <bens>
Group administrator
Wed 16 Mar 2022 06:37:26 PM UTC, comment #8: 

For what it's worth I did manage to walk gnulib back and find the breaking commit, though of course not nano-specific, but for your reference anyway:

87e6634b28df65084321fed22f60d114a0931d21 is the last working, so this breaks it:

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=0c8a563f65d44752b33aec42cceec25bd485f2d5

Now.. to dig into mailinglist stuff to report it once I have some time again.. I wish they had a bugs list like nano. :(

For now I'll just build nano for Android with gnulib frozen at the last working. If you ever want to check it out:

https://github.com/Magisk-Modules-Repo/nano-ndk
https://forum.xda-developers.com/t/tools-zips-scripts-osm0sis-odds-and-ends-multiple-devices-platforms.2239421/

Thanks for your help Benno, keep up the good work!

Chris Renshaw <osm0sis>
Mon 14 Mar 2022 11:05:07 AM UTC, comment #7: 

Closing, as it is not a bug in nano itself.

Benno Schulenberg <bens>
Group administrator
Wed 02 Mar 2022 04:11:50 PM UTC, comment #6: 

Thanks.  Then please post the error output as-is (and the normal, successful output) to bug-gnulib.  (But first maybe check whether it's already fixed: cd gnulib && git checkout master && git pull && cd - ; comment out lines 32-44 in autogen.sh, then run ./autogen.sh and make.)

Benno Schulenberg <bens>
Group administrator
Wed 02 Mar 2022 12:55:19 PM UTC, comment #5: 

My install of Cygwin's automake is 1.16.1 by the way, so I guess that rules out that part of things at least.

Chris Renshaw <osm0sis>
Wed 02 Mar 2022 11:41:21 AM UTC, comment #4: 

I've got a newborn at home, so I don't have much time to look into anything too deeply at the moment, definitely no time to bisect libgnu.

autotools and Makefile generation certainly worked fine in nano 6.0 builds, that's all I know beyond the errors vs. clean output posted already.

Chris Renshaw <osm0sis>
Wed 02 Mar 2022 10:57:41 AM UTC, comment #3: 

Any more info on this?

Benno Schulenberg <bens>
Group administrator
Mon 28 Feb 2022 10:15:14 AM UTC, comment #2: 

In the command that fails, there is a lone hyphen (after -D_DEFAULT_SOURCE), which seems to indicate that something went wrong in the Makefile generation.

Benno Schulenberg <bens>
Group administrator
Mon 28 Feb 2022 09:46:42 AM UTC, comment #1: 

What comes to mind is: maybe autotools is too old?  (See for example https://lists.gnu.org/archive/html/bug-gnulib/2022-02/msg00010.html.)

If it's not that, then please report the issue to bug-gnulib at gnu dot org (no need to subscribe).  When reporting the problem there, it would be nice to be able to point at the offending commit.  Bisecting gnulib within nano goes easiest when commenting out the "Make sure" block in ./autogen.sh (lines 32-44).

Benno Schulenberg <bens>
Group administrator
Mon 28 Feb 2022 03:02:07 AM UTC, original submission:  

Compiles have worked on my build set up (Cygwin and Android NDK), up to and including nano 6.0, but 6.1 and later have broken compiles due to some change with libgnu:

make[4]: Entering directory '/home/Chris/nano-6.2/lib'
arm-linux-androideabi-gcc -std=gnu11 -DHAVE_CONFIG_H -I. -I..   -D_GNU_SOURCE -D_DEFAULT_SOURCE    - -Wno-unsuffixed-float-constants -D__ANDROID_API__=21 -O3 -ffunction-sections -s -Wall -MT libgnu_a-basename-lgpl.o -MD -MP -MF .deps/libgnu_a-basename-lgpl.Tpo -c -o libgnu_a-basename-lgpl.o `test -f 'basename-lgpl.c' || echo './'`basename-lgpl.c
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
: Invalid argumentabi-gcc.exe: error:
make[4]: * [Makefile:2485: libgnu_a-basename-lgpl.o] Error 1
make[4]: Leaving directory '/home/Chris/nano-6.2/lib'
make[3]: * [Makefile:4227: all-recursive] Error 1
make[3]: Leaving directory '/home/Chris/nano-6.2/lib'
make[2]: * [Makefile:2230: all] Error 2
make[2]: Leaving directory '/home/Chris/nano-6.2/lib'
make[1]: * [Makefile:1750: all-recursive] Error 1
make[1]: Leaving directory '/home/Chris/nano-6.2'
make: * [Makefile:1691: all] Error 2

I can reproducibly check out the v6.0 tag and get a working compile which succeeds past this part of the libgnu build without issue:

make[4]: Entering directory '/home/Chris/nano-6.0/lib'
depbase=`echo basename-lgpl.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
arm-linux-androideabi-gcc -std=gnu11 -DHAVE_CONFIG_H -I. -I..   -D_GNU_SOURCE -D_DEFAULT_SOURCE    -D__ANDROID_API__=21 -O3 -ffunction-sections -s -Wall -MT basename-lgpl.o -MD -MP -MF $depbase.Tpo -c -o basename-lgpl.o basename-lgpl.c &&\
mv -f $depbase.Tpo $depbase.Po

Thanks!

Chris Renshaw <osm0sis>

 

(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 bens (Posted a comment)
  • -email is unavailable- added by osm0sis (Submitted the item)
  • -email is unavailable- added by osm0sis
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-14 bens Open/ClosedOpen Closed
    2022-03-14 bens Assigned toNone bens
    2022-03-02 bens Summarylibgnu build failure on Cygwin+Android NDK for nano 6.1 and later gnulib build failure on Cygwin+Android NDK for nano 6.1 and 6.2
    2022-02-28 bens Summarylibgnu Cygwin+Android NDK build crash on nano 6.1 and later libgnu build failure on Cygwin+Android NDK for nano 6.1 and later
    2022-02-28 osm0sis Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code