[Top][All Lists]
[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: |
Tue, 20 Apr 2010 12:26:04 -0700 |
This in the gnulib stdint.h:
/* Get those types that are already defined in other system include
files, so that we can "#define int8_t signed char" below without
worrying about a later system include file containing a "typedef
signed char int8_t;" that will get messed up by our macro. Our
macros should all be consistent with the system versions, except
for the "fast" types and macros, which we recommend against using
in public interfaces due to compiler differences. */
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? Or is this existence check hard to do universally
right?
For example, OSX defines _INT64_T to mark the typedef for int64_t, but there is
no corresponding marker for the uint64_t.
The above aim for consistency does not currently hold, whenever the native
int64_t is "long long" or "long long int", and uint64_t is "unsigned long long"
or "unsigned long long int". In these cases the current definitions of the
corresponding macros (int64_t and uint64_t) in gnulib/stdint.h break the ABI.
I do not know if other systems than OSX are affected, but this needs to be
fixed. Current definitions already have special cases for specific
environments, so I would start with this:
--- a/lib/stdint.in.h
+++ b/lib/stdint.in.h
@@ -135,7 +135,8 @@ typedef unsigned int gl_uint32_t;
/* Do not undefine int64_t if gnulib is not being used with 64-bit
types, since otherwise it breaks platforms like Tandem/NSK. */
-#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__))
# undef int64_t
typedef long int gl_int64_t;
# define int64_t gl_int64_t
@@ -152,7 +153,8 @@ typedef long long int gl_int64_t;
# define GL_INT64_T
#endif
-#if ULONG_MAX >> 31 >> 31 >> 1 == 1
+/* OSX needs uint64_t to be "long long" rather than "long int" */
+#if ULONG_MAX >> 31 >> 31 >> 1 == 1 && !(defined (__APPLE__) && defined
(__MACH__))
# undef uint64_t
typedef unsigned long int gl_uint64_t;
# define uint64_t gl_uint64_t
More elegant solutions could be done later, if need be. One would be to test
the presence of the corresponding typedefs at configure time and then not
redefine them, if they exist already.
Regards,
Jarno
On Apr 16, 2010, at 3:59 PM, ext Paolo Bonzini wrote:
> On 04/17/2010 12:12 AM, Jarno Rajahalme wrote:
>> With this patch the ABI compatibility is maintained, and linking
>> succeeds.
>
> It would likewise start to fail on Linux, though.
>
>> maybe a configure time check for int64_t is needed.
>
> Yes. Already defined types should not be redefined.
>
> Paolo
>
>
>
- gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX, fix included, Jarno Rajahalme, 2010/04/08
- gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX, Jarno Rajahalme, 2010/04/15
- Gnulib 64-bit ABI bug with OSX, generic patch proposed, Jarno Rajahalme, 2010/04/16
- Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed, Jarno Rajahalme, 2010/04/16
- Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed, Paolo Bonzini, 2010/04/16
- Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed,
Jarno Rajahalme <=
- Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed, Paul Eggert, 2010/04/23
- Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed, Jarno Rajahalme, 2010/04/25
- Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed, Jarno Rajahalme, 2010/04/26
- Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed, Jarno Rajahalme, 2010/04/30