[ As per Ralf's suggestion, starting a new thread on a tangential issue... ]
I'm looking at sox-12.17.9 and seeing in their "configure" file (which
claims to be generated via Autoconf 2.59) from their configure.in file
and seeing:
ac_cv_sizeof_x="$ac_cv_sizeof_char:$ac_cv_sizeof_short"
ac_cv_sizeof_X="$ac_cv_sizeof_x:$ac_cv_sizeof_int"
ac_cv_sizeof_X="$ac_cv_sizeof_X:$ac_cv_sizeof_voidp:$ac_cv_sizeof_long"
if test "$ac_cv_header_stdint" = "stddef.h" ; then
# we must guess all the basic types. Apart from byte-adressable system,
# there a few 32-bit-only dsp-systems. nibble-addressable systems are way off.
cat >>$ac_stdint_h <<EOF
/* ------------ BITSPECIFIC INTTYPES SECTION --------------- */
EOF
t="typedefs for a"
case "$ac_cv_sizeof_X" in
1:2:2:2:4) echo "$as_me:$LINENO: result: ..adding $t normal 16-bit system" >&5
echo "${ECHO_T}..adding $t normal 16-bit system" >&6
cat >>$ac_stdint_h <<EOF
/* a normal 16-bit system */
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;
#ifndef __int8_t_defined
#define __int8_t_defined
typedef char int8_t;
typedef short int16_t;
typedef long int32_t;
#endif
EOF
;;
...
and wondering what is going on with the ac_cv_sizeof_X variable?
On my cross-compile platform (a Geode LX700), I'm getting:
1:2:4::4
as the value. Apparently we didn't define the size of a void *... (not
sure why there's both charp/char_p and voidp/void_p combinations out
there... would be nice to have uniformity.)
Seems that, had we forced ac_cv_sizeof_voidp=4 in the autoconf
invocation, this would have forced:
1:2:4:4:4) echo "$as_me:$LINENO: result: ..adding $t normal 32-bit system" >&5
echo "${ECHO_T}..adding $t normal 32-bit system" >&6
cat >>$ac_stdint_h <<EOF
/* a normal 32-bit system */
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
#ifndef __int8_t_defined
#define __int8_t_defined
typedef char int8_t;
typedef short int16_t;
typedef int int32_t;
#endif
EOF
;;
instead.
I did a quick search, and it seems that other packages also use this
ac_cv_sizeof_X convention.
Is this encouraged? Discouraged?
It seems to me that more useful would be the converse, i.e.
--with-nominal-32bit-sizes or whatever forcing all the standard sizes
(instead of having to specify each).
I'm also not sure why there's "ac_cv_sizeof_long" and
"ac_cv_sizeof_long_int", etc. except perhaps to make the cross-compiling
distro-manager's life hellish. :-)
Likewise with the "ac_cv_sizeof_charp" versus "ac_cv_sizeof_char_p", and
"ac_cv_sizeof_char" versus "ac_cv_sizeof_unsigned_char" (are these
*ever* different???).
Is any of this covered somewhere where a distro manager can get up to
speed on the usual pitfalls when adding a new package to a
cross-compiled build?
And is there a "autoconf-lint" to check for using broken names, like
"ac_cv_sizeof_long_long_unsigned_int" instead of whatever is preferred?
Thanks,
-Philip
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
