On Tue, 08 Jul 2008 15:42:25 +0200
Andreas Schwab <schwab@xxxxxxx> wrote:
>"Philip A. Prindeville" <philipp@xxxxxxxxxxxxxxxxxxxxx> writes:
>
>> 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)
>
>You are looking at an old version of autoconf. The current definition
>of AC_CHECK_SIZEOF does not use the second argument any more and use a
>pure compile-time check when cross compiling.
Oh, I was not aware of the 2nd argument of AC_CHECK_SIZEOF().
BTW, when I checked the development toolchains for 16bit ELKS
(Embedded Linux Kernel Subset) distributed by Debian GNU/Linux:
bcc 0.16.17-2 16-bit x86 C compiler
bin86 0.16.17-2 16-bit x86 assembler and loader
elks-libc 0.16.17-2 16-bit x86 C library and include files
configure detects the sizes of int, long are zero.
I attached the tarball that I tested. I think it's
primarily by the bug of bcc (not of autoconf), bcc
does not issue an error in the compilation that
should not be compiled successfully. But I wish if
autoconf has any workaround, or pre-checking of
bcc to avoid the trouble. Other legacy C compilers
(in 16bit era) are tested and known to work well?
Regards,
mpsuzuki
Attachment:
bcc-test.tar.bz2
Description: Binary data
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
