4:index.m4:28: ERROR: end of file in argument list
> make: *** [../Makefile.mk:38: m5] Error 1
> davin@davins:~/Public/sources/50webs-com$
This is in a different directory than the source and build directory of m4.
We can't help you debug arbitrary code / scripts / Makefiles that you happen
> CC c-stack.o
> In file included from /usr/include/signal.h:328,
> from ./signal.h:52,
> from c-stack.c:49:
> c-stack.c:55:27: error: missing binary operator before token "("
>55 | #elif HAVE_LIBSIGSEGV && (SIGSTKSZ < 16384)
> |
davin@davins:~/Downloads/m4-1.4.18$ sudo make install
make install-recursive
make[1]: Entering directory '/home/davin/Downloads/m4-1.4.18'
Making install in .
make[2]: Entering directory '/home/davin/Downloads/m4-1.4.18'
make[3]: Entering directory '/home/davin/Downloads/m4-1.4.18'
make[3]: Nothin
.com<mailto:osm0...@outlook.com>;
bug-gnulib@gnu.org<mailto:bug-gnulib@gnu.org>
Subject: Re: [BUG REPORT] gnulib Android NDK and/or Cygwin build failure
regression after 0c8a563f
On 4/3/22 19:22, osm0...@outlook.com wrote:
> Examined a copy of the conftest.out file the script parses
On 4/3/22 19:22, osm0...@outlook.com wrote:
Examined a copy of the conftest.out file the script parses those from and
noticed it had CR+LF due to being from Windows Android NDK and/or on Cygwin,
Sounds like your Cygwin shell is misconfigured. You might try setting
SHELLOPTS='igncr' in your en
The differences between the invoking commands in the build outputs I shared had
a good clue, which was the new "- -Wno-unsuffixed-float-constants" in the
broken one that was added by the breaking commit, but there should have been
more options than that and the lone " - " definitely appeare
Paul Eggert wrote:
> On 4/6/22 01:24, arn...@skeeve.com wrote:
> > Most people
> > would wonder "Why is there a bitwise and here?" and not think of it
> > as a logical and.
>
> I'm not sure I agree about the "most", as I expect most people won't
> notice or care about this level of detail. Howev
On 4/6/22 01:24, arn...@skeeve.com wrote:
Most people
would wonder "Why is there a bitwise and here?" and not think of it
as a logical and.
I'm not sure I agree about the "most", as I expect most people won't
notice or care about this level of detail. However, for people who
wonder like that,
On 4/6/22 03:28, Bernhard Voelker wrote:
Well, it was an argument to say that & eliminates a conditional execution
branch, but if both sides of the & operator have to be evaluated
They don't. Neither operand has side effects, so a compiler can evaluate
either operand and not bother to evaluate
On 4/6/22 10:24, arn...@skeeve.com wrote:
> I'll stick to my opinion that && is better here since we're doing
> logical tests; the short-circuit nature of && is less important.
_
Well, it was an argument to say that & eliminates a con
Paul Eggert wrote:
> On 4/6/22 00:04, arn...@skeeve.com wrote:
> > IMHO clear code beats saving a single branch
>
> Sure, but clarity also argues for "&" over "&&" here. Writing "f(x) &&
> f(y)" would incorrectly imply that it's important that f(y) should not
> be evaluated when f(x) is false,
On 4/6/22 00:04, arn...@skeeve.com wrote:
IMHO clear code beats saving a single branch
Sure, but clarity also argues for "&" over "&&" here. Writing "f(x) &&
f(y)" would incorrectly imply that it's important that f(y) should not
be evaluated when f(x) is false, an implication that is incorrec
> On 4/5/22 22:18, arn...@skeeve.com wrote:
> > dfa.c:1093:27: warning: use of bitwise '&' with boolean operands
> > [-Wbitwise-instead-of-logical]
Paul Eggert wrote:
> It's valid in C to use bitwise '&' on bool, and doing so here eliminates
> a conditional branch at the machine level, which
On 4/5/22 22:18, arn...@skeeve.com wrote:
dfa.c:1093:27: warning: use of bitwise '&' with boolean operands
[-Wbitwise-instead-of-logical]
It's valid in C to use bitwise '&' on bool, and doing so here eliminates
a conditional branch at the machine level, which can be a win.
How about if yo
Hi.
Thanks for the report. I am cc'ing the GNULIB guys, as they
are the upstream for dfa.c. In the meantime, I will make this
change in gawk.
Thanks!
Arnold
David Binderman wrote:
> Hello there,
>
> I just tried to compile gawk-5.1.1 with new clang-14. It said
>
> dfa.c:1093:27: warning: u
The differences between the invoking commands in the build outputs I shared had
a good clue, which was the new "- -Wno-unsuffixed-float-constants" in the
broken one that was added by the breaking commit, but there should have been
more options than that and the lone " - " definitely appeare
On 3/21/22 13:30, Chris Renshaw wrote:
: Invalid argumentabi-gcc.exe: error:
That's a little cryptic. Could you explain a bit more what the problem is?
the breaking change is from
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=0c8a563f65d44752b33aec42cceec25bd485f2d5
That cha
Hi! I was advised to send this issue here by Benno @ GNU nano since it seems to
be a regression in libgnu building with Android NDK and/or Cygwin. Here's the
nano bug report, for reference: https://savannah.gnu.org/bugs/?62124
I build nano for Android using this setup and bisected libg
Hi,
comex wrote:
> From m4/lib-prefix.m4:
>
> --
> AC_CACHE_CHECK([for ELF binary format], [gl_cv_elf],
> [AC_EGREP_CPP([Extensible Linking Format],
>[#ifdef __ELF__
> Extensible Linking Format
> #endif
>],
>[gl_cv_elf=yes],
>[gl_cv_elf=no])
>
On Sun, Nov 29, 2020 at 9:43 PM comex wrote:
>
> From m4/lib-prefix.m4:
>
> --
> AC_CACHE_CHECK([for ELF binary format], [gl_cv_elf],
> [AC_EGREP_CPP([Extensible Linking Format],
>[#ifdef __ELF__
> Extensible Linking Format
> #endif
>],
>[gl_cv_elf=yes
From m4/lib-prefix.m4:
--
AC_CACHE_CHECK([for ELF binary format], [gl_cv_elf],
[AC_EGREP_CPP([Extensible Linking Format],
[#ifdef __ELF__
Extensible Linking Format
#endif
],
[gl_cv_elf=yes],
[gl_cv_elf=no])
])
if test $gl_cv_elf; then
—
I b
Looking at that test's source code, the test was clearly incorrect for
Unix-like systems, as it incorrectly assumed a 1-1 mapping between user
names and user IDs. I fixed that in Gnulib by installing the attached
patch. Wolfgang, could you please try this on your Linux from Scratch
system? You
Regarding https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27640 :
Hello Wolfgang,
What type of system is this? You are saying "Linux From Scratch version 8.0".
What type of libc is it using? There are several competing ones [1].
> > FAIL: test-getlogin
> > ===
> >
> > test-getlogi
On 10/07/17 00:46, Wolfgang F. Muthmann wrote:
> FAIL: test-getlogin
> ===
>
> test-getlogin.c:92: assertion 'strcmp (pwd->pw_name, buf) == 0' failed
> FAIL test-getlogin (exit status: 134)
Forwarding to gnulib
thanks,
Pádraig
Sorry - wrong list. Please ignore.
On Mon, Sep 01, 2014 at 01:30:32PM +0200, Aaron Sowry wrote:
> Hi,
>
> I've noticed that if the gnulib git tree is used as a submodule for a
> different
> project, the git detection in the bootstrap script will not work properly.
> This
> is because it checks
Hi,
I've noticed that if the gnulib git tree is used as a submodule for a different
project, the git detection in the bootstrap script will not work properly. This
is because it checks for the existence of a .git directory, whereas for
submodules .git will be a file.
The fix is trivial, patch att
On 02/01/2012 02:22 AM, Bruno Haible wrote:
> I find it overkill to change the code for HP-UX and NonStop systems
> when the report is about Solaris. Also I think the structure of the loop
> is not the problem; it is the code's reaction to
> acl("x", ACE_GETACL, 4, 0x3432A16E0)Err#-1
Paul Eggert wrote:
> Thanks, can you please try the attached patch?
I find it overkill to change the code for HP-UX and NonStop systems
when the report is about Solaris. Also I think the structure of the loop
is not the problem; it is the code's reaction to
acl("x", ACE_GETACL, 4, 0x3432A16E0)
On 01/30/2012 07:01 PM, JONES, BILL wrote:
> those are vxfs.
Thanks, can you please try the attached patch?
You can apply it by running the shell commands:
cd lib
patch < vxfs-patch.txt
I'll CC: this to bug-gnulib as it appears to be a Gnulib bug.
Thanks.
acl: fix infinite loop on Solaris 1
On 05/02/11 03:25, Bruno Haible wrote:
The bug is that while sharutils does not use libtool, in src/Makefile.am
it uses $(LTLIBINTL) when it should use $(LIBINTL).
Fixed in source. Build under way. I'll re-release when I get the next
opportunity. Thank you all. Regards, Bruce
Howdy Bruce!
I notice that the latest sharutils relies on iconv.m4 and friends from
gnulib to provide --with-libiconv-prefix and --with-libintl-prefix.
But, these macros are assuming that you will link using libtool, which
knows how to translate -R arguments into -R/-rpath/-Wl,-rpath/-blibpath
etc
Hi Bruce,
On Sun, May 01, 2011 at 01:46:18PM +, Gary V. Vaughan wrote:
> I notice that the latest sharutils relies on iconv.m4 and friends from
> gnulib to provide --with-libiconv-prefix and --with-libintl-prefix.
> But, these macros are assuming that you will link using libtool, which
> knows
Gary V. Vaughan wrote:
> > I notice that the latest sharutils relies on iconv.m4 and friends from
> > gnulib to provide --with-libiconv-prefix and --with-libintl-prefix.
> > But, these macros are assuming that you will link using libtool,.
No, they don't. They define a variable for use with li
On 05/01/11 06:46, Gary V. Vaughan wrote:
Howdy Bruce!
Hi Gary!
I notice that the latest sharutils relies on iconv.m4 and friends from
gnulib to provide --with-libiconv-prefix and --with-libintl-prefix.
But, these macros are assuming that you will link using libtool,.
m4/gnulib-cache.m4
When building coreutils-8.11 on Irix 6.3 and Tru64 Unix 5.1, linking
of sort always fails because LIB_PTHREAD=''. Looking through src/
Makefile.am shows that LIBMULTITHREAD='-lpthread' in both cases,
but sort links with LIB_PTHREAD which is empty, leaving pthread
symbols unresolved.
I'm guessing
Andreas Stolcke wrote:
> On a i386-pc-solaris2.7 system, mktemp goes into an infinite loop.
> The wrapper function definition for gettimeofday() is broken, so
> the function keeps calling itself.
Thanks for the report and patch.
This relates to gnulib, so I've Cc'd that list.
> *** lib/gettimeofd
Jim Meyering <[EMAIL PROTECTED]> writes:
> That looks fine.
OK, I installed it into coreutils. Also into gnulib.
I'm CC:ing this message to bug-gnulib so here is the patch again,
relative to gnulib. The original bug report is here:
<http://lists.gnu.org/archive/html/bug-
Yuri Vasilevski wrote:
On Thu, 25 Aug 2005 12:49:37 -0700
Paul Eggert <[EMAIL PROTECTED]> wrote:
Yuri Vasilevski <[EMAIL PROTECTED]> writes:
Recent versions of sed expect glibc behavior [from] malloc, i.e.
malloc(0) return live pointer. This is not true for uClibc (and many
other old/classical
Chuck Swiger <[EMAIL PROTECTED]> writes:
> In general, code which assumes that malloc() will never
> return NULL is missing a basic sanity check and will result in bugs.
Yes, and that's why gnulib has a malloc wrapper that addresses this
issue systematically. The wrapper handles this sanity chec
Yuri Vasilevski <[EMAIL PROTECTED]> writes:
> Also glibc's realloc return NULL if size == 0, so in the places where
> realloc is used in regex the case of NULL pointers most be taken care
> off in any way.
I just checked, and regex never uses size == 0 with realloc, so we're
OK there. (This assu
Hi
On Thu, 25 Aug 2005 12:49:37 -0700
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Yuri Vasilevski <[EMAIL PROTECTED]> writes:
>
> > Recent versions of sed expect glibc behavior form malloc, i.e.
> > malloc(0) return live pointer. This is not true for uClibc (and many
> > other old/classical libc im
Yuri Vasilevski <[EMAIL PROTECTED]> writes:
> Recent versions of sed expect glibc behavior form malloc, i.e.
> malloc(0) return live pointer. This is not true for uClibc (and many
> other old/classical libc implementations).
Thanks, but I'd rather not go through the glibc regex implementation
loo
42 matches
Mail list logo
