For what it's worth, GCC 4.5 does not have this problem, as the gnulib stdint.h tests pass, so it is not replaced. But this is specific to GCC 4.5, which is not supported by Apple...
Jarno On Apr 26, 2010, at 8:37 AM, Jarno Rajahalme wrote: > > On Apr 24, 2010, at 8:58 PM, ext Jarno Rajahalme wrote: > >> >> On Apr 23, 2010, at 3:04 PM, ext Paul Eggert wrote: >> >>> Jarno Rajahalme <jarno.rajaha...@nsn.com> writes: >>> >>>> So it seems that the aim is for the gnulib/stdint.h types and the >>>> macros be consistent with the system versions. If so, why not use the >>>> system versions for defining them, if they exist? >>> >>> Because the system versions are often wrong. gnulib/m4/stdint.m4 >>> contains a fairly strict test of the system version, and if this test >>> fails, we don't trust the system version. >>> >>>> -#if LONG_MAX >> 31 >> 31 == 1 >>>> +/* OSX needs int64_t to be "long long" rather than "long int" */ >>>> +#if LONG_MAX >> 31 >> 31 == 1 && !(defined (__APPLE__) && defined >>>> (__MACH__)) >>> >>> This is not the Autoconf Way. We should instead test (in stdint.m4) >>> that the system stdint.h defines int64_t to an appropriate type, and if >>> so, set a flag that stdint.in.h uses to avoid redefining int64_t. Can >>> you write a patch along those lines? >> >> >> Sorry, I can't parse stdint.m4. If it is up to me, it'll take some time to >> come up to speed with the Autoconf Way. >> > > I looked into this over the weekend. It seems to me that stding.m4 already > conducts all the necessary tests, but falls short in the sense that if > anything fails, the whole stdint.h is replaced. In the case of OSX, the > UINT8_C and UINT16_C tests fail to pass. If gnulib stdint.m4 replaced only > these definitions, there would be no problem. > > I guess that configure should parse the compiler output (errors) and define > corresponding macros for replacement, and then have gnulib stdint.h use those > macros to replace only the broken parts. > > Jarno >
