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. _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
