Re: Issues w/ cross-compiling

[Philip A. Prindeville]

Ralf Wildenhues wrote:
> * 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
>   

What about:

const unsigned size_int = sizeof(int);

then groveling the output of the compiler in -S -pipe mode for 'size_int'?

-Philip