Re: [open-axiom-devel] ECL build is broken
A system for computer algebra and symbolic mathematics
Brought to you by:
dos-reis
From: Aleksej S. <as...@in...> - 2009-11-07 14:55:01
|
Gabriel Dos Reis <gd...@cs...> writes: > Aleksej Saushev <as...@in...> writes: > > [...] > > | > | gmake[2]: Entering directory `/tmp/wip/openaxiom/work/open-axiom/src/lisp' > | > | gmake[2]: *** gmake[2]: Entering directory `/tmp/wip/openaxiom/work/open-axiom/src/hyper' > | > | oa_enable_lisp_profiling= nil > | > | No rule to make target `core.o', needed by `../../i486--netbsdelf/lisp/core.o'../../libtool --mode=compile cc -c -o addfile.o -O2 -mfpmath=sse -msse3 -march=nocona -finline-functions -fomit-frame-pointer -ffast-math -I/usr/pkg/include -O2 -Wall -I../../src/include -I../../config -I. addfile.c > | > | . Stop. > | > | > | > | > | > | Also, I see this: > | > | > | > | hthits.c: In function 'handleFile': > | > | hthits.c:292: warning: format '%ld' expects type 'long int *', but argument 4 has type 'time_t *' > | > | hthits.c:292: warning: format '%ld' expects type 'long int *', but argument 4 has type 'time_t *' > | > | > | > | And I think it is a bad idea, because of: > | > | > | > | #define _BSD_TIME_T_ __int64_t > | > > | > which is not a standard data type. What is the corresponding scanf format? > | > | Probably the easiest way is using intmax_t ("%jd") or uintmax_t ("%ju") > | and converting the input result. > > This would require that I have a C99 compiler and library or at least > a compiler and library that understand those times. I know that on > open-solaris, that is a nightmare to get right. I would have expected > that on *BSD, a long is 64-wide if there support for 64-bit integer > datatypes... Alright, let's try another way. scanf(3) lists this: q Indicates that the conversion will be one of dioux or n and the next pointer is a pointer to a quad_t (rather than int). /usr/include/sys/types.h:typedef uint64_t u_quad_t; /* quads */ /usr/include/sys/types.h:typedef int64_t quad_t; stdlib.h pulls these definitions in. It is so on NetBSD and Dragonfly, I expect it to be on FreeBSD same way. OTOH, Dragonfly documentation declares it deprecated. Dragonfly scanf(3) mentions this instead: ll (ell ell) Indicates that the conversion will be one of dioux or n and the next pointer is a pointer to a long long int (rather than int). Same on FreeBSD. Not so on NetBSD, though test program using "%lld" does work. I consider it documentation bug. -- HE CE3OH... |