nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] compilation problem


From: Ansuel Smith
Subject: Re: [Nano-devel] compilation problem
Date: Mon, 2 Sep 2019 20:23:28 +0200

linaro = optimized version of gcc 4.8

Yes i'm crosscompiling
The errors are not related to nano compilation (invalid revision)

The strange part is that the check part actually check if max_align is
"good" but in the compilation process it does complain about this.. So
i think the gnulib should be modified to fix this.




Il giorno lun 2 set 2019 alle ore 17:29 Benno Schulenberg
<address@hidden> ha scritto:
>
>
> [When you respond, please reply only to the mailing list.]
>
>
> Op 02-09-19 om 14:00 schreef Ansuel Smith:
> > I'm using linaro gcc 4.8
>
> What *is* linaro gcc?
>
> > and i think nano have some problem with it.
>
> Have you compiled nano before on that system?  If yes, which was
> the last nano you could compile successfully there?
>
> > ansuel@Ansuel-Gaming:~/openwrt$ make package/nano/compile V=s
> > fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..HEAD
> > fatal: Invalid revision range
>
> ??  What are these errors?
>
> Are you cross compiling?
>
> > In file included from ./scratch_buffer.h:9:0,
> >                  from malloc/scratch_buffer_grow.c:23:
> > ./malloc/scratch_buffer.h:69:3: error: unknown type name 'max_align_t'
>
> The error occurs while trying to compile a gnulib module.  My system
> does not have 'max_align_t' defined in any /usr/include header file either,
> but compilation succeeds.  Using gcc-7.4.0 or clang-6.0.0 here.
>
> I don't know what's the problem.  Some googling brings up this:
>
>   https://github.com/emscripten-core/emscripten/issues/6660
>
>
> Grepping the gnulib source with:
>
>    grep -A2 "lack max" lib/stddef.in.h
>
> /* Some platforms lack max_align_t.  The check for _GCC_MAX_ALIGN_T is
>    a hack in case the configure-time test was done with g++ even though
>    we are currently compiling with gcc.  */
>
> I don't understand any of that code, but maybe you can work around
> the problem by removing the two #ifs from line 87 and 88 in that file
> (and the corresponding #endifs on line 109 and 100, of course).
>
> Benno
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]