Dagobert Michelsen <dam(a)opencsw.org> writes:
> I see different possibilities on how this can be resolved:
>
> 1. nettle uses the gnulib definitions
I currently have no plans to switch to using gnulib.
As far as I'm aware, there's no problem with the types which nettle
actually uses. So it would be a reasonable workaround to simply not
define the int_fast*_t types; then they won't collide with the
incompatible definitions gnutls gets from gnulib. Question is just
what's the least intrusive way to do that (*if* it's easy to avoid, I'd
prefer not to modify the definition of AX_CREATE_STDINT_H). I would
appreciate if you can try the workarounds I suggested the other day and
let me know how it works.
> 2. gnulib changes the definitions to conform to nettle
The problem with gnulib is not primarily that it doesn't "conform to
nettle", but that it defines some types in a way that differs both from
<stdint.h> on later releases on the OS (where the types are included),
and from the definition in the stdint.h which comes with gcc.
So code which uses the int_fast*_t types and relies on gnulib will get a
slightly different ABI if compiled on SunOS-5.9 (or earlier) using Sun's
compiler, than if compiled with gcc on the same system, or compiled with
Sun's compiler on any later release of the OS. I think that's what needs
to be fixed in gnulib. Do the gnulib folks agree?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
