On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote:
From: Christian Ehrhardt <[EMAIL PROTECTED]>
*update*
further debugging according to some requests revealed that ARCH_CFLAGS does
not contain all CFLAGS that might be needed, especially those supplied via
extra-cflags. Therefore people supplying things via extra-cflags instead of an
environment variable might have had issues.
This part i don't get, there are few more checks before/after
hostlongbits where no CFLAGS are added to the $cc argument list. What
makes hostlongbits selection "special"? Do people specify -m32/-m64 via
--extra-cflags?
A recent kvm merge with qemu brought code for 64bit power that broke cross
compilation. The issue is caused by configure trying to execute target
architecture binaries where configure is executed.
Yes, i never thought about cross-compilation, my bad.
I tried to change that detection so that it works with&without cross
compilation with only a small change and especially without an addtional
configure command line switch. Including the bits/wordsize.h header a platform
usually can check its wordsize and by doing that configure can check the
hostlongbits without executing the binary. Instead it now stops after
preprocessing stage which resolved the __WORDSIZE constant and retrieves
that value.
I don't like my new check style, but it is at least less broken than before.
Another approach that was suggested was that qemu might end up needing
something like asm-offsets in the kernel to manage architecture sizes etc.
Comments and other approaches welcome.
I think Hollis Blanchard's method is sound,
Thank you for bringing this up.
--
mailto:[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
