Issues w/ cross-compiling

[Philip A. Prindeville]

I was wondering who I might work with to resolve some issues having to 
do with cross-compilation.

For instance, sometimes building i386 targets on x64 architecture will 
cause issues, or else building i586-uClibc targets on FC7 and x64 will 
cause the compiler to make broken assumptions about what the target 
sizes are for "int", "long", "long long", etc.

Looking at sequences like:

echo $ac_n "checking size of size_t""... $ac_c" 1>&6
echo "configure:17119: checking size of size_t" >&5
if eval "test \"`echo '$''{'ac_cv_sizeof_size_t'+set}'`\" = set"; then
 echo $ac_n "(cached) $ac_c" 1>&6
else
 if test "$cross_compiling" = yes; then
 ac_cv_sizeof_size_t=8
else


which comes from:

build_i586/php-5.2.6/configure.in:AC_CHECK_SIZEOF(size_t, 8)


and is more than a little suspect.

May I suggest that the 2nd argument to AC_CHECK_SIZEOF() is an extremely 
bad idea, and should be banished post haste?

And if you have a include/bits/types.h file to search from, why not grab 
the sizes (in bits) of various types directly from there?  (True, this 
is a linuxism.... I'm sure a lot of other platforms have similar headers 
we can tailor to...)

Looking at this file on a particular cross-development project I'm 
working on, I see:

typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;

I can surmise correctly that the default value for 
AC_CHECK_SIZEOF(unsigned int) should be 4, for instance.

Or from:

typedef signed int __int32_t;
...
typedef int __ssize_t;                  /* Type of a byte count, or 
error.  */

Ok, slightly more work, but AC_CHECK_SIZEOF(size_t) should be 4 also. 
(Yes, I left out a step involving bits/kernel_types.h...)

At a minimum, could we add a flag to autoconf that would cause it to 
fail if it encountered any instances of AC_CHECK_SIZEOF() with a second 
argument...

I noticed some other issues with cross-compilation in various packages, 
but there doesn't seem to be an easy fix to this.

If I have time, I'll try to triage the sorts of frequent failures to 
accommodate cross-compilation that I encounter, and see if there's any 
sort of commonality that we could exploit...

Thanks,

-Philip