Dagobert Michelsen dam@opencsw.org writes:
I just verified that the problem persists with nettle 2.4 and gnutls-3.0.19. As you seem to have access to the Solaris buildfarm it would be cool if you could finally fix this as it blocks new releases of gnutls for the OpenCSW distribution.
It's some time since I looked in to this. My understaning of the problem is that
1. This Solaris version lack both <stdint.h> and <inttypes.h>. (A comment in AX_CREATE_STDINT_H seems to imply that it does have a <sys/inttypes.h>, should we use that?)
2. Nettle defines uint32_t and friends using the AX_CREATE_STDINT_H autoconf macro.
3. gnulib defines them in a different way.
4. The multiple definitions of, e.g., uint32_t, agree and are no problem.
5. The definitions of some other (unused) types are incompatible, e.g., int_fast8_t, and cause the compilation errors.
6. The definitions from AX_CREATE_STDINT_H is compatible with the definitions of these types in Solaris 10. gnulib's definitions aren't, so any code using them can potentially break if linked together with code compiled on Solaris 10.
Hence I think it ought to be fixed in gnulib. Simon (and any other gnulib people on these lists), do you agree?
To address (1), maybe you can try
diff --git a/configure.ac b/configure.ac index 6bf2b8b..77bb9b1 100644 --- a/configure.ac +++ b/configure.ac @@ -518,7 +518,7 @@ LSH_GCC_ATTRIBUTES
# According to Simon Josefsson, looking for uint32_t and friends in # sys/types.h is needed on some systems, in particular cygwin. -AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h]) +AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h], [sys/inttypes.h])
# Check for file locking. We (AC_PROG_CC?) have already checked for # sys/types.h and unistd.h.
but I suspect you would still get compilation errors due to incompatible definitions in gnulib and sys/inttypes.h.
Maybe the easiest nettle workaround would be to somehow disable the definitions of the problematic types, which we don't use anyway.
Could you try something like the following?
diff --git a/nettle-types.h b/nettle-types.h index b694332..d0aa332 100644 --- a/nettle-types.h +++ b/nettle-types.h @@ -23,6 +23,9 @@ #ifndef NETTLE_TYPES_H #define NETTLE_TYPES_H
+/* Pretend this type always exists. Nettle doesn't use it. */ +#define _STDINT_HAVE_INT_FAST32_T 1 + #include "nettle-stdint.h"
#ifdef __cplusplus
Have a look into the generated nettle-stdint.h (or the template in aclocal.m4) for other potentially useful defines.
The closest Solaris 5.8 box I used to have acccess to (hanna.lysator.liu.se) seems to have been decomissioned.
Regardss, /Niels
fre 2012-04-27 klockan 14:54 +0200 skrev Niels Möller:
Dagobert Michelsen dam@opencsw.org writes:
I just verified that the problem persists with nettle 2.4 and gnutls-3.0.19. As you seem to have access to the Solaris buildfarm it would be cool if you could finally fix this as it blocks new releases of gnutls for the OpenCSW distribution.
It's some time since I looked in to this. My understaning of the problem is that
- This Solaris version lack both <stdint.h> and <inttypes.h>. (A comment in AX_CREATE_STDINT_H seems to imply that it does have a <sys/inttypes.h>, should we use that?)
Using system headers if available seems like a good idea.
Nettle defines uint32_t and friends using the AX_CREATE_STDINT_H autoconf macro.
gnulib defines them in a different way.
What is the difference? This sounds bad.
- The definitions of some other (unused) types are incompatible, e.g., int_fast8_t, and cause the compilation errors.
If they are unused, we could remove the definitions.
- The definitions from AX_CREATE_STDINT_H is compatible with the definitions of these types in Solaris 10. gnulib's definitions aren't, so any code using them can potentially break if linked together with code compiled on Solaris 10.
Hence I think it ought to be fixed in gnulib. Simon (and any other gnulib people on these lists), do you agree?
Yes. Understanding what the differences is, and which one is right, seems useful first though. If the problem is in gnulib, we can fix that and GnuTLS will have the new variant soon.
/Simon
Simon Josefsson simon@josefsson.org writes:
Yes. Understanding what the differences is, and which one is right, seems useful first though. If the problem is in gnulib, we can fix that and GnuTLS will have the new variant soon.
Quoting my investigation from an old (off-list) email thread, from November last year:
And the problem seems to be that inttypes.h doesn't define int_fast8_t types. And then AX_CREATE_STDINT_H (used by nettle) and gnulib (used by gnutls) both decide to define them, and they do that in an incompatible way.
---
From a quick look at gl/stdint.h.in and on posted error messages, I think glib uses long for all of int_fast8_t, int_fast16_t and int_fast32_t, and int64_t for int_fast64_t, while nettle uses int8_t, int, int32_t and int64_t.
---
Actually, one ought to have a look at the definitions in the stdint.h provided by gcc (and at the definitions in the solaris10 stdint.h), and make sure the definitions of the int_fast* types are equivalent. Otherwise one might end up with subtle ABI differences and errors when linking together code compiled by different compilers.
Agreed.
I did a quick check. The following seems to be the correct sizes:
int_fast8_t: 1 int_fast16_t: 4 int_fast32_t: 4 int_fast64_t: 8
This is using sizeof on the types defined in stdint.h, trying:
gcc -m32 on solaris 9 gcc -m64 on solaris 9 cc -m32 on solaris 10 cc -m64 on solaris 10
Remarkably enough, they all agree. I also get the same sizes from nettle-stdint.h, for both 32 bit and 64 bit configurations. So I think nettle (or really, AX_CREATE_STDINT_H) gets this right.
While if I understand gl correctly, it uses 4,4,4,8 for a 32-bit build and 8,8,8,8 for a 64-bit build (the size of long is different). This seems wrong. Sure, these are perfectly ok sizes according to C99, but they differ from the sparc conventions (and possibly conventions for other architectures as well).
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
nisse＠lysator.liu.se -
Simon Josefsson