[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues w/ cross-compiling
From: |
Ralf Wildenhues |
Subject: |
Re: Issues w/ cross-compiling |
Date: |
Tue, 8 Jul 2008 22:57:24 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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