Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

[Yann Dirson]

On Thu, Sep 23, 2010 at 07:30:20PM +0200, Gunnar Farneb?ck wrote:
> On 09/23/10 19:28, Yann Dirson wrote:
> >On Wed, Sep 22, 2010 at 11:16:26PM +0200, Gunnar Farneb?ck wrote:
> >>Ok, I understand the fuseki database issue now. Just to make sure, is
> >>it infeasible to let the target platform run extract_fuseki
> >>(transforming fusekiN.dbz to fusekiN.c)?
> >
> >Well, the whole point of cross-compiling is not using the target -
> >esp. the OE distros are built on servers which have no access to any
> >target.
> 
> I sort of suspected that would be the case.
> 
> >Nonetheless, I have thought about that: if one needs such a handful of
> >files, they could be generated once on the target and kept in a
> >per-target patch.  But it looks like that's overkill in my case.
> 
> It should be possible to avoid. But there's something fundamentally
> fishy about running configure on the host platform and then compile
> for the target platform based on configure tests for the host. Or
> maybe I'm missing something. Is SIZEOF_LONG for the target available
> in the build somehow?

configure does report results for the compiler's target platform
(which autostuff calls "host machine", it reserves "target machine" to
talk about the target of a toolchain when we are building one - so the
"canadian cross" setup is building on a "build machine" a compiler
that will run on "host machine" to build binaries for "target
machine" - now *that* is fishy ;)

> Here's an experiment you could try. After running configure on your
> 64-bit machine, change SIZEOF_LONG to 4, then do your cross-build and
> see if fusekiN.c compiles better.

It correctly reports SIZEOF_LONG as 4 when I cross-compîle, and 8 when
I compile natively.  But since my "build machine" printf's 64bit
longs, the cross-compiler with 32bit longs issues truncation warnings.