Re: build-aux file permissions

Is there any reason your autoupdates to the build-aux directory remove executable permissions? For example: Sorry. Perhaps the files I am copying aren't executable; I admit I haven't checked recently since it's not an issue with CVS. (Not that I'm claiming CVS's behavior is preferable,

Re: why require 2.60 in m4/getdelim.m4?

Eric Blake <[EMAIL PROTECTED]> wrote: > Jim Meyering meyering.net> writes: ... >> you increased the minimum version of automake from 2.52 to 2.60. > > Because I added a use of AC_CHECK_DECLS_ONCE, which was only introduced after > 2.59. But I see that gnulib already works around this case, so ple

Re: why require 2.60 in m4/getdelim.m4?

Jim Meyering meyering.net> writes: > Hi Eric, Hi Jim, > you increased the minimum version of automake from 2.52 to 2.60. Because I added a use of AC_CHECK_DECLS_ONCE, which was only introduced after 2.59. But I see that gnulib already works around this case, so please apply your patch. > S

why require 2.60 in m4/getdelim.m4?

Hi Eric, In this change, http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=33c8286ea93bec94c46 you increased the minimum version of automake from 2.52 to 2.60. Since libvirt is starting to use gnulib, and has a pretty hard requirement that it work with autoconf-2.59, I need to know why

Re: [PATCH]: gl_recursive_lock_init issue with pthread backend

Le vendredi 07 décembre 2007 à 12:17 +0100, Bruno Haible a écrit : > Yoann Vandoorselaere wrote: > > I'm worried about lock initialization. If initializing a mutex fail, the > > application should be allowed to handle it gracefully. > > In all cases I know of, a lock initialization is nothing m

Re: Support versions of autoconf prior to 2.59c.

Jim Meyering <[EMAIL PROTECTED]> wrote: > I discovered that gnulib-tool requires autoconf-2.59c or newer > for autoconf's m4_foreach_w macro. This change lets > gnulib-tool work also with autoconf-2.59. > > This was necessary for libvirt, when running their ./autogen.sh > script on a RHEL5 system

Re: OpenBSD frexpl failure

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 12/5/2007 9:08 PM: >>> It looks like float.in.h needs to be updated to cater for another platform >>> with a broken . >> Can you try it out (change float_h.m4, float.in.h, and then run a testdir >> with >> tests from frexpl,

Re: mingw isnanl-nolibm failure

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/7/2007 4:19 AM: > > Either this, or ensure that the "checking where to find the exponent" tests > return the bit positions instead of "unknown". > > But I don't see how to implement either of these two possible fixes f

Re: no license on some test modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/7/2007 4:18 AM: > > A fix could be to make func_import work a bit like func_create_testdir, but > with a single configure file: > - Put the configure tests for 'xalloc' into the normal configure. This is > OK sinc

Re: Patch for the getpagesize module

Martin Lambers wrote: > Do you want to replace the getpagesize function from libgcc.a on MinGW > with the implementation above? Or do you want the implementation above > only for native Windows variants that don't have getpagesize? The former. The function from libgcc.a is maybe not correct in al

Re: mingw isnanl-nolibm failure

Eric Blake wrote: > When compiling natively on mingw: > ... > checking where to find the exponent in a 'long double'... word 2 bit 0 > checking where to find the exponent in a 'long double'... (cached) word 2 bit > 0 > > and the resulting rpl_isnanl works. > > But when cross-compiling: > ... > ch

Re: no license on some test modules

Hi Jim, > Of course, including the tests is solely so that we can get > better test coverage Sure, that's the purpose. > I noticed that several test modules don't specify a > license, which makes gnulib-tool --lgpl fail. > ... > I can see a couple ways of fixing it, assuming you are game: > -

Re: base64 build problem on DragonFly 1.8.0

Martin Lambers wrote: > Jeremy C. Reed received the following bug report about building > mpop-1.0.12 on DragonFly 1.8.0. > This version of mpop uses current gnulib files from 2007-11-27. > > > Here is the error when attempting to build base64.o: > > > > In file included from /usr/include/wchar.

Re: [PATCH]: gl_recursive_lock_init issue with pthread backend

Yoann Vandoorselaere wrote: > I'm worried about lock initialization. If initializing a mutex fail, the > application should be allowed to handle it gracefully. In all cases I know of, a lock initialization is nothing more than a memcpy. I'm not worried about it. > Some applications provide threa