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 …
[View More]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
[View Less]
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/…
[View More]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 $
[View Less]
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
--…
[View More]
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
[View Less]
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
…
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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, …
[View More]int_fast*_t, etc.). [1]
Is there a gnulib module that only provides the basic types?
regards,
Nikos
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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.
[View Less]