[I'm cross-posting to the nettle list and a debian bug, so please take care when replying]
The issue is that there are some differences in generated nettle header files depending on architecture and compiler version.
Francois Gouget fgouget@free.fr writes:
Here is a proposed patch for the compiler version issue in nettle-stdint.h:
$ cat debian/patches/multiarch.patch --- a/aclocal.m4 +++ b/aclocal.m4 @@ -857,7 +857,7 @@ fi # shortcircut to system "stdint.h" # ------------------ PREPARE VARIABLES ------------------------------ if test "$GCC" = "yes" ; then -ac_cv_stdint_message="using gnu compiler "`$CC --version | head -1` +ac_cv_stdint_message="using gnu compiler $CC" else ac_cv_stdint_message="using $CC" fi
If we go this path, maybe just drop the conditional and unconditionally print "using $CC"? I'm not sure about the reason for displaying the version, but I guess some older gcc versions did stdint and/or inttypes.h differently.
If you have the time, it would be helpful to look at the latest version of AX_CREATE_STDINT_H (from autoconf archive) and see if it does anything differently. Nettle uses a pretty old version (which seems to work fine).
For GMP_NUMB_BITS here are some thoughts:
You must understand that nettle defines GMP_NUMB_BITS only if configured with --enable-mini-gmp. This configuration is not intended to be compatible with anything else, and should never be installed on a normal debian system. It's intended for small embedded systems which needs to verify digital signatures, but which consider the real libgmp too large.
- Is it really necessary to install version.h? IMHO the right place for other packages to figure out library versions is through some scripting in the configure script rather than through a header.
This has been requested by users. Not everyone uses autoconf. And it's very common practice, I think both gmp and gnutls have similar version defines.
- GMP_NUMB_BITS is already defined by libgmp-dev in gmp.h. More
preceisely
Exactly, and when not configuring with --enable-mini-gmp, that's the definitions which is used.
Getting into the details, Nettle's definition of GMP_NUMB_BITS conceptually belongs in mini-gmp.h. However, mini-gmp is a standalone package which doesn't use autoconf. And it has to be a preprocessor *constant*, so definiting it like sizeof(unsigned long) * CHAR_BIT won't cut it, since the preprocessor doesn't understand sizeof.
Therefore the definition, for the --enable-mini-gmp configuration which needs it, should be in a nettle include file. Then the cleanest way would be to omit the definition completely when not using --enable-mini-gmp. I haven't done that, because it would make the substitution logic harder, and because I was thinking that
#define NETTLE_USE_MINI_GMP 0 #if NETTLE_USE_MINI_GMP # define GMP_NUMB_BITS 64 #endif
is harmless whatever value appears in the second define. If it helps, I guess this could be changed into the architecture independent
#define NETTLE_USE_MINI_GMP 0 #if NETTLE_USE_MINI_GMP # define GMP_NUMB_BITS the moon is made of green cheese #endif
Opinions?
Regards, /Niels
On Sat 2015-05-23 04:37:40 -0400, Niels Möller wrote:
The issue is that there are some differences in generated nettle header files depending on architecture and compiler version.
If the differences are significant (e.g. if there are structs, functions, or #defines that are declared differently based on architecture and compiler version) then we can also just ship the .h files in /usr/include/${ARCH_TRIPLE}/nettle/ instead of /usr/include/nettle/. This can make the nettle-dev package co-installable across architectures. (e.g. nettle-dev:i386 could be installed alongside nettle-dev:amd64 without the files colliding, since they're at different places in the filesystem)
Take a look at the libgpg-error-dev package in debian, which ships its header files in the multi-arch include directories.
since nettle is using pkg-config instead of some kind of /usr/bin/nettle-config script, and pkg-config is already multi-arched, nettle-dev could do even better at being multi-arch compatible than libgpg-error-dev.
That said, if there are no significant differences in any of the architectures that debian supports, i don't think that embedding the exact version of the compiler used to generate the .h files is actually useful, and it would be great to reduce superfluous variance.
--dkg
nettle-bugs@lists.lysator.liu.se