On 01/15/2013 05:01 PM, PHO wrote: > * lib/autoconf/specific.m4 (AC_SYS_LARGEFILE): This macro was > accidentally defining _DARWIN_USE_64_BIT_INODE with AH_VERBATIM so the > variable was defined even when $enable_largefile = no. The bug also > caused inconsistency between AH_HEADER and confdefs.h thus > AC_COMPUTE_INT(VAR, [sizeof(ino_t)]) produced a wrong result, > i.e. 32-bit ino_t for configuration time and 64-bit ino_t for > build/run time. > ---
Thanks for the report. but I don't think this patch is quite right. Can you please provide more details, such as a minimal configure.ac to provoke the issue, and the resulting config.h that gets generated incorrectly? > lib/autoconf/specific.m4 | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4 > index bbfa24a..4b20a63 100644 > --- a/lib/autoconf/specific.m4 > +++ b/lib/autoconf/specific.m4 > @@ -171,8 +171,9 @@ if test "$enable_largefile" != no; then > AH_VERBATIM([_DARWIN_USE_64_BIT_INODE], > [/* Enable large inode numbers on Mac OS X 10.5. */ > #ifndef _DARWIN_USE_64_BIT_INODE > -# define _DARWIN_USE_64_BIT_INODE 1 > +# undef _DARWIN_USE_64_BIT_INODE > #endif]) Unconditionally undefining a macro when it is already inside an #ifndef block is pointless. Are you stating that you don't need the AH_VERBATIM at all, and can instead just use an AC_DEFINE to get the semantics you want? And these days, compiling without large file support is rather anti-climactic; gnulib, for example, has already decided that it is much easier to always insist on large file support than it is to try to make it user-configurable. > + AC_DEFINE([_DARWIN_USE_64_BIT_INODE], [1]) > fi > ])# AC_SYS_LARGEFILE > > -- > 1.8.0.1 > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
