[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: |
Wed, 9 Jul 2008 00:03:02 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
* Philip A. Prindeville wrote on Tue, Jul 08, 2008 at 11:44:08PM CEST:
> Ralf Wildenhues wrote:
>> 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.
> What about using 'nm'? Generate an object file (or intermediate object
> file) with two adjacent symbols (packed) of the same size, and subtract
> the difference in addresses?
Well, having to rely on 'nm' to even exist is a bit of a pain.
For example, the bin86 package that is used along with bcc has
the program named nm86, which a tool check would not have found
automatically. Then, the nm output format is poorly standardized
(see Libtool), relying on the order a compiler outputs symbols is
AFAIK not safe. Plus, packing would lead to the wrong solution
(AC_CHECK_SIZEOF is intended to return the result that sizeof would,
not that sizeof of the packed version of the type would).
The proposed ideas of fixing AC_LANG_BOOL_COMPILE_TRY(C) may be pursued.
Or bcc fixed. Or you may be able to get by with binfmt_misc (this is
actually described in a README for elks-libc). There are however more
issueswhen using that. For one, the Autoconf testsuite test
172: C keywords
causes bcc to get stuck in an endless loop outputting an error, which
just managed to fill my work partition...
Cheers,
Ralf