bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jarno Rajahalme
Subject: Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed
Date: Fri, 30 Apr 2010 20:30:40 -0700

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 <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
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]