[Xorg-driver-geode] [PATCH] Allow compilation under 64 bit systems
q-funk at iki.fi
Wed Jun 23 08:45:56 PDT 2010
On Wed, Jun 23, 2010 at 6:33 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
> On Wed, 2010-06-23 at 18:10 +0300, Martin-Éric Racine wrote:
> On Wed, Jun 23, 2010 at 5:57 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
>> On Wed, 2010-06-23 at 14:35 +0800, Huang, FrankR wrote:
>> Is that to say this solve method will let the geode compilation
>> but in un-use status? Only for the whole build success of the X.org tree?
>> - We (as in X.Org) get bug reports as compilation fails on 64 bit. People
>> don't know so they ask.
> For this, I prefer your initial idea of issuing a warning and
> gracefully skipping src/ on non-x86 architectures.
>> - People other than pure Geode developers make contributions and many have
>> 64 bit systems. It could be in Autotools only, like I do,
>> it could be fixing code due to server API changes, like yesterday.
>> anything that is safe to do without the need of loading the driver on the
>> real hardware.
>> It is a simple matter of making it easy for others to contribute.
> For that, wouldn't prepending -m32 to the compiler flags ensure that
> the driver can be built on x86_64 and still generate x86_32
> instructions always?
> I am open to an equivalent solution. I tried -m32 on durango.c:
> /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or
> The problem isn't generated code but the inline assembler in the source
> durango.c:203: Error: suffix or operands invalid for `push'
> 203: " push %%ebx\n" It should be %%rbx for 64 bit.
> There may be an easy way to tell the compiler to handle this situation.
For 64-bit, yes, but not for 32-bit. The problem seems to be about
telling the CPU to switch context before launching GCC. I wonder how
this could be done.
PS: Gaetan, could you please check your MUA setting?. For some reason,
most of the time, it fails to properly indent the message you're
More information about the Xorg-driver-geode