nettle-bugs

nettle-bugs@lists.lysator.liu.se

4 participants
2224 discussions

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by Dagobert Michelsen 23 May '12

23 May '12

Hi, Am 08.05.2012 um 23:17 schrieb Paul Eggert: > On 05/08/2012 01:05 PM, Niels Möller wrote: >> I think it should work fine to just get the gnutls release and apply >> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the >> configure script. > > Yes, that's the idea. Thanks. Sorry for the delay, I got distracted. I just tested the latest stdint.in.h from gnulib master and gnutls 3.0.19 passes this stage now. However, I didn't change anything on the nettle includes and now get lots of warnings. Probably the gl_* definitions should not belong to the installed nettle headers? CC pkcs12_bag.lo "/opt/csw/include/nettle/nettle-stdint.h", line 237: warning: typedef redeclared: gl_int_fast8_t "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: typedef redeclared: gl_int_fast16_t "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: typedef redeclared: gl_int_fast32_t "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef redeclared: int64_t "/opt/csw/include/nettle/nettle-stdint.h", line 244: warning: typedef redeclared: gl_uint_fast8_t "/opt/csw/include/nettle/nettle-stdint.h", line 245: warning: typedef redeclared: gl_uint_fast16_t "/opt/csw/include/nettle/nettle-stdint.h", line 246: warning: typedef redeclared: gl_uint_fast32_t "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef redeclared: uint64_t Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896

2 1

Configure problem on OS-X
by William Morris 21 May '12

21 May '12

Hi. I obtained the latest nettle using git. Running 'configure' on OS-X (10.7.4) fails. config.status: error: cannot find input file: config.h.in Any ideas? Output from 'configure' given below. -- William Morris iMac:nettle $ ./configure checking build system type... x86_64-apple-darwin11.4.0 checking host system type... x86_64-apple-darwin11.4.0 checking for -R flag... none Searching for libraries checking /usr/local/lib/lib... not found checking /usr/local/lib... added checking /sw/local/lib... not found checking /sw/lib... not found checking /usr/gnu/lib... not found checking /opt/gnu/lib... not found checking /sw/gnu/lib... not found checking /usr/freeware/lib... not found checking /usr/pkg/lib... not found checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make sets $(MAKE)... yes checking for ranlib... ranlib checking for nm... nm checking for objdump... no checking for a BSD-compatible install... /usr/bin/install -c checking for a thread-safe mkdir -p... ./install-sh -c -d checking whether ln -s works... yes configure: Compiler uses 64-bit ABI. To change, set CC. configure: WARNING: Don't know where to install 64-bit libraries on this system. configure: Libraries to be installed in ${exec_prefix}/lib. configure: Looking for assembler files in x86_64/. checking CCPIC... -fPIC checking if globals are prefixed by underscore... yes checking if we should use a .note.GNU-stack section... no checking for ELF-style .type,%function pseudo-ops... no checking for ELF-style .type,#function pseudo-ops... no checking if .align assembly directive is logarithmic... yes checking for m4... /usr/bin/m4 checking for an ANSI C-conforming const... yes checking for inline... inline checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for uid_t in sys/types.h... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for long... yes checking size of long... 8 checking for uint64_t... yes checking alignment of uint64_t... 8 checking openssl/blowfish.h usability... yes checking openssl/blowfish.h presence... yes checking for openssl/blowfish.h... yes checking openssl/des.h usability... yes checking openssl/des.h presence... yes checking for openssl/des.h... yes checking openssl/cast.h usability... yes checking openssl/cast.h presence... yes checking for openssl/cast.h... yes checking openssl/aes.h usability... yes checking openssl/aes.h presence... yes checking for openssl/aes.h... yes checking for working alloca.h... yes checking for alloca... yes checking malloc.h usability... no checking malloc.h presence... no checking for malloc.h... no checking for strerror... yes checking whether byte ordering is bigendian... no checking for memxor... no checking for __attribute__... yes checking for stdint types... stdint.h (shortcircuit) make use of stdint.h in nettle-stdint.h (assuming C99 compatible system) checking for fcntl file locking... yes checking for __gmpz_getlimbn in -lgmp... no configure: WARNING: GNU MP not found, or not 3.1 or up, see http://gmplib.org/. Support for public key algorithms will be unavailable. checking for __gmpz_powm_sec... no checking for BF_ecb_encrypt in -lcrypto... yes checking for library containing clock_gettime... no configure: creating ./config.status config.status: creating config.make config.status: creating config.m4 config.status: creating Makefile config.status: creating tools/Makefile config.status: creating testsuite/Makefile config.status: creating examples/Makefile config.status: creating nettle.pc config.status: creating hogweed.pc config.status: error: cannot find input file: config.h.in iMac:nettle $

2 1

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 08 May '12

08 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Thanks. This seems to be a win regardless of whether it > fixes the nettle problems, Dago, can you test if it solves the SunOS-5.9 problem for you? I.e., apply Paul's patch to gnutls/gnulib, then *unapply* the nettle workaround I comitted yesterday, and see if you still get compilation errors related to nettle-stdint.h. I'm not sure how picky the compiler is about multiple but equivalent typedefs of the same name. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 08 May '12

08 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Such usage violates the C standard: even if one compiler > is not picky about it, your're likely to run into another that > does. So a better solution is needed. I've committed a workaround to nettle-types.h. It now does /* Pretend these types always exists. Nettle doesn't use them. */ #define _STDINT_HAVE_INT_FAST32_T 1 #include "nettle-stdint.h" which overrides the result of the configure checks used in the generated nettle-stdint.h. Maybe not the prettiest way to do it, but apparantly it solves the problem, independently of your fixes to gnulib. (But I'd still like to know if your fixes also solves this problem, independently of that Nettle workaround). > I'd rather have an approach where the code simply does "#include > <stdint.h>" and assumes that int_fast8_t works. I don't understand the > overall situation, though, so I don't know what exactly to suggest. I think when you build gnutls on a system lacking stdint.h, a typical compilation unit will contain /* From gnulib's stdint.h */ typedef unsigned int gl_uint32_t; #define uint32_t gl_uint32_t ... /* From nettle/nettle-stdint.h */ typedef unsigned int uint32_t; where the final line is macro-expanded to typedef unsigned int gl_uint32_t; >From what I've seen, this has been no problem. And I hope nettle-stdint.h and gnulib/stdint.h always do these types in the same way. There is some freedom in how to define these types; on a system where for example int and long are the same size, typedef unsigned long uint32_t; typedef unsigned int uint32_t; would be a two distinct but correct definitions, and I imagine the compiler would complain. And to consider the problematic int_fast*_t types, until a day or two ago, you got /* From gnulib's stdint.h */ typedef long gl_int_fast8_t; #define int_fast8_t gl_int_fast8_t ... /* From nettle/nettle-stdint.h */ typedef char int_fast8_t; which no reasonable compiler will accept. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 07 May '12

07 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not > mention int_fast*_t, except in stdint.h where C requires their definition. I'd consider that definition to be authoritative... > Presumably this is for the same reason that Gnulib avoids these types. > Arguably these types are not part of the SunOS 5.10 ABI, since nothing > in the SunOS library binary interface use them. C is still the system programming language, and int_fast*_t are part of the language. But maybe we're splitting hairs now. > The main reason is to keep gnulib simple and maintainable. > I'd rather not have to hand-maintain details about an > operating system that hasn't shipped since 2009. I thought the point of gnulib was to do those annoying things to keep the maintanance in one place. But I guess I'll have to leave to the judgment of the gnulib maintainers which systems are too old and obsolete to care about. > How does the nettle stuff work? Does it #define int_fast8_t etc > in config.h? It is defined in a generated file nettle-stdint.h. And the names of the types are all typedefs, no #defines. With AX_CREATE_STDINT_H, it's a file generated independently of config.h. The file starts with a section with a bunch of #defines set up by configure, and then the rest of the file uses various tests on these to decide what file to include and which types to define. Where the common case is to just include the system's <stdint.h>. The file is then installed with the other nettle header files. > If so, there's a simple workaround in gnulib: > don't futz with int_fast8_t if it's already #defined. If one could get that to work, it might solve the problem for the case that the types are defined but not used. But if it implies that size of those types will depend on #include order, it seems very brittle to me. I think it would be better to let the gnulib application say explicitly whether or not it needs those types, and not define them at all in the common case that they aren't needed. I.e., #ifdef GL_WANT_INTX_FAST_T # define int_fast8_t gl_int_fast8_t #endif Not sure where one would define GL_WANT_INTX_FAST_T, if desired, though. Should be specified in some way in configure.ac, but it can't be put in config.h if the stdint.h types are needed for installed header files. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 06 May '12

06 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Intuitively, it's because the int_fast* types are so fragile: they > depend so much on choice of compiler and compiler option. Short version: I think gnulib should either make an effort to define int_fast*_t in the common way on each system (always doing the same as gcc would be very close to the Right Thing), or by default generate a stdint.h without these types and define the int_fast*_t types only when explicitly asked to. Longer version (sorry I fail to be more concise): I think I misread "public headers" in your previous mail, I thought you meant system header files, rather than public header files provided by portable non-system libraries. Sorry for the confusion. I agree one can expect these types to be a fragile and compiler dependent whenever they're left undefined by system headers and ABI spec, which will be the usual assumption for portable code. But in the particular case of SunOS, the types are defined by system headers in release 5.10 (and presumably nailed down by the ABI spec), but missing in release 5.9. Do you see any good reason for gnulib to not define the types in the same way as on 5.10, if building on 5.9? To me, that really looks like the Right Thing to do, and it also looks like the kind of job gnulib is supposed to do. Defining them in a way which differs from SunOS-5.10 definitely seems broken. In the case of gnutls and nettle, one gets compilation errors when another packed defines the same types, and does it using a configure hack which *is* compatible with SunOS-5.10. Of course, that fix doesn't magically make int_fast*_t universally non-fragile, but it definitely improves compatibility for the system in question. As for nettle, I think it's best to not define these types, which aren't used. On Solaris, it happens that AX_CREATE_STDINT_H defines them more correctly (in my view) than gnulib, but it may well cause problems on other system, so it seems more robust to not try to define them at all. But please also consider the hypothetical situation that nettle *did* use those types, even if only internally. Then I couldn't simply omit the definitions. To not cause problems for gnulib users I'd be forced to either change my definitions to prefer compatibility with gnulib over compatibility with SunOS-5.10, which seems really backwards, or introduce additional complexity in nettle-stdint.h to omit the definitions when my public headers need uint32_t. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 06 May '12

06 May '12

Bruno Haible <bruno(a)clisp.org> writes: > It doesn't exist so far. But it is feasible. - On the other hand, it > looks like nettle-stdint.h can already be easily trimmed in this way, > by undefining _STDINT_NEED_INT_LEAST_T and _STDINT_NEED_INT_FAST_T ? I think that makes sense. I just need someone (Dagobert Michelsen?) who can try it out. Nettle uses the AX_CREATE_STDINT_H macro to generate that file. If it's easy, I'd prefer not to touch that and just add some extra #define in nettle-types.h before it includes nettle-stdint.h. Or if that doesn't work out, it's fine to hack away in the definition in aclocal.m4 to take out the unneded types. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by Nikos Mavrogiannopoulos 06 May '12

06 May '12

On 05/06/2012 12:34 PM, Bruno Haible wrote: > Niels Möller wrote: >> One possibility might be to not define the types at all, unless the >> gnulib application explicitly asks for them. Lots of applications want >> uint32_t, and I imagine a lot fewer have any need for int_fast*_t. > Yes. For this reason, libunistring installs a trimmed-down version of > gnulib's stdint.h, that defines only the int{8,16,32}_t types and not > all the rest (int64_t, int_least*_t, int_fast*_t, etc.). [1] Is there a gnulib module that only provides the basic types? regards, Nikos

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by Dagobert Michelsen 06 May '12

06 May '12

Hi Niels, Am 06.05.2012 um 07:02 schrieb Paul Eggert: > On 05/05/2012 12:19 PM, Niels Möller wrote: >> So code which uses the int_fast*_t types and relies on gnulib will get a >> slightly different ABI > > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. > This is a documented issue in Gnulib. > It's hard to imagine a general fix for this. Do you see a chance to adjust the nettle header files to avoid the fast-types? The current situation makes gnutls uncompilable on platforms like Solaris. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 06 May '12

06 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. Why (feel free to point to the relevant section of gnulib docs, if it's explained well there)? Maybe nobody uses these types so it's an academic issue, but if these types are used in the interface to any library (possibly some system library), then it's important that applications agree on the definition. To me, it seems like the authoritative definition of int_fast*_t ought to be the system's ABI specification. And in the case of SunOS-5.9, where the types are missing, I think it makes the most sense to adopt the ABI of SunOS-5.10. Which also seems to be what gcc does. I'm a bit confused by your statement. I had the impression that gnulib *does* fall back on the definitions in public headers like <stdint.h> and <inttypes.h>, for the types which *are* defined there. And that's why nettle and gnutls seem to work together on SunOS-10. Correct? > This is a documented issue in Gnulib. > It's hard to imagine a general fix for this. One possibility might be to not define the types at all, unless the gnulib application *explicitly* asks for them. Lots of applications want uint32_t, and I imagine a lot fewer have any need for int_fast*_t. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs