Re: Issues w/ cross-compiling

[Ralf Wildenhues]

Hello,

* address@hidden wrote on Tue, Jul 08, 2008 at 04:20:44PM CEST:
> 
> 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.

This is odd.  I can confirm it though: bcc ("Bruce’s C compiler")
doesn't throw a compile error for

int
main ()
{
static int test_array [1 - 2 * !(((long int) (sizeof (int))) <= 1)];
test_array[0] = 0

  ;
  return 0;
}


Linking errors out in this case with
| ld86: data segment too large for 16bit

but that error doesn't instill a lot of confidence in the quality of the
compiler.  I do not know, though, whether that's even conflicting with
the standard -- does it specify that constraint errors need to be
emitted at the compilation phase?

I do get a compile error with

int
main ()
{
static int test_array [1 - 2 * !(((long int) (sizeof (int))) <= 1)];
return sizeof test_array

  ;
  return 0;
}


so I'm wondering whether we should change the test.  Changing
AC_LANG_BOOL_COMPILE_TRY(C) in a way so that it doesn't ever
warn (thus getting _AC_COMPUTE_INT_COMPILE to silently return
bogus results), isn't completely trivial, though
(unreachable code vs. code that is optimized away).

> 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?

I have no idea.  But Autoconf is pretty old, at least
it already existed at a time where 16bit was very common.

If you have a way to actually execute code on the compile
system (get binfmt to execute 'elksemu $binary' should be
possible), then you can avoid compile-only tests and make
AC_COMPUTE_INT use the cheaper execution test.

Cheers,
Ralf