On 11/19/2010 04:15 PM, Mike Frysinger wrote: > On Friday, November 19, 2010 11:46:23 Paul Eggert wrote: >> On 11/18/2010 10:48 PM, Mike Frysinger wrote: >>> this is because m4/stdint.m4 only defines HAVE_SYS_INTTYPES_H when >>> gl_cv_header_working_stdint_h is "no" and i my case, it's yes. >> >> Sorry, I'm lost. If gl_cv_header_working_stdint_h is "yes" >> then why is gnulib stdint.h being used at all? >> >> Is this a clean build, or was there a stdint.h left over from >> a previous build? > > sort of a clean build. process is: > ./configure --host=<some system which needs lib/stdint.h> > make > make clean > ./configure --host=<some system which doesnt need lib/stdint.h> > make > > doing a `make distclean` instead makes things work, but doesnt seem like it > should be necessary over `make clean`
It's a known issue that we leave replacement headers around that don't get cleaned up except on make distclean, even if something changes that no longer needs the header to be generated. If you want to quickly test multiple systems across a shared tree, I'd recommend VPATH builds rather than 'make clean'. Meanwhile, for headers where we always supply the replacement, in order to support GNULIB_POSIXCHECK, it is not an issue. Maybe this argues that we should improve our stdint.h to work with GNULIB_POSIXCHECK, and always be a valid replacement file even when there's nothing to fix? But what does <stdint.h> provide that GNULIB_POSIXCHECK would be able to warn about? -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
