[PATCH] bypass broken inline strtod() definition in on Mingw

2010-06-10 Thread Ben Pfaff
Cross-compiling lib/strtod.c failed on Mingw, as reported at http://savannah.gnu.org/bugs/?29965: strtod.c:37: error: redefinition of 'strtod' /usr/i686-pc-mingw32/sys-root/mingw/include/stdlib.h:319: note: previous definition of 'strtod' was here The problem was the section of stdli

RE: bug#6053: cp, ls, and mv bug: unknown error (252)

2010-06-10 Thread Callahan, Patrick M.
Thanks for the details. Do you care about ACLs? If not, then building --without-acl should be fine. [>> Right now we don't really care about ACLs and I had already built [>> the tools as you suggested --without-acl support. If you do require that ACLs be preserved in general, then more work will

[PATCH] correct a now-inaccurate statement in gnulib-intro.texi

2010-06-10 Thread Ben Pfaff
I pushed this out. --8<--cut here-->8-- >From e04f62a982976bfa16f6c7e4ec7ee5e6b46e8996 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Thu, 10 Jun 2010 20:11:05 -0700 Subject: [PATCH] Replacement header templates are now named with ".in", not "_".

Re: btw, gl_SNPRINTF_RETVAL_C99 was expanded before it was required...

2010-06-10 Thread Bruno Haible
Hi Jim, > When running the new test, > > ./gnulib-tool --create-testdir --with-tests --test inttostr > > I saw lots of warnings like this go by: > > configure.ac:170: warning: AC_REQUIRE: `gl_SNPRINTF_RETVAL_C99' was > expanded before it was required > glm4/vasnprintf.m4:15: gl_RE

Re: uninstalling relocation wrappers

2010-06-10 Thread Ralf Wildenhues
Hi Ben, * Ben Pfaff wrote on Thu, Jun 10, 2010 at 07:06:53AM CEST: > +uninstall-hook: uninstall-relocwrapper > +uninstall-relocwrapper: Nice. > +if RELOCATABLE_VIA_LD > + @: > +else > + if test $(RELOCATABLE) = yes; then \ > + case '$(EXEEXT)' in \ > + .bin*) ;; \ > +

[PATCH] inttostr-tests: depend on snprintf, not snprintf-posix

2010-06-10 Thread Jim Meyering
I've just noticed that snprintf-posix includes this notice: Comment: This module should not be used as a dependency from a test module, otherwise when this module occurs as a tests-related module, it will have side effects on the compilation of the 'vasnprintf' module, if that

Re: [PATCH] gnulib-tool: List modules separately, explicit vs dependencies.

2010-06-10 Thread Thien-Thi Nguyen
() Bruno Haible () Fri, 2 Apr 2010 10:32:18 +0100 I apologize for the delayed response. If you just cut randomly, you will introduce bugs in your package, for sure. There are two reasonable uses of '--avoid': 1) When the documentation of the modules mentions that a module

Re: bug#6053: cp, ls, and mv bug: unknown error (252)

2010-06-10 Thread Pádraig Brady
On 10/06/10 14:32, Eric Blake wrote: > On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote: >> if ((errno == ENOSYS || errno == EOPNOTSUPP) >> ... >> You could get in a debugger and determine where >> to add "|| errno == 252" to solve what appears to be >> an HP-UX-and/or-cvfs-specific probl

Re: bug#6053: cp, ls, and mv bug: unknown error (252)

2010-06-10 Thread Eric Blake
On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote: > if ((errno == ENOSYS || errno == EOPNOTSUPP) > ... > You could get in a debugger and determine where > to add "|| errno == 252" to solve what appears to be > an HP-UX-and/or-cvfs-specific problem. > > However, such a change is not appro

btw, gl_SNPRINTF_RETVAL_C99 was expanded before it was required...

2010-06-10 Thread Jim Meyering
When running the new test, ./gnulib-tool --create-testdir --with-tests --test inttostr I saw lots of warnings like this go by: configure.ac:170: warning: AC_REQUIRE: `gl_SNPRINTF_RETVAL_C99' was expanded before it was required glm4/vasnprintf.m4:15: gl_REPLACE_VASNPRINTF is expande

Re: [PATCH] inttostr: add a new function, inttostr

2010-06-10 Thread Jim Meyering
Jim Meyering wrote: > Bruno Haible wrote: > ... >> This is not complete. You also need to tell Automake to compile the >> inttostr.c >> file, either through a >> lib_SOURCES += inttostr.c >> line in the module description, or in m4/inttostr.m4. > > Thanks. > I'll add tests, too. > >> Since we ha