Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed

[Jarno Rajahalme]

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 <address@hidden> 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