[Xorg-driver-geode] proposal: always build with -march=geode

Writer, Tim Tim.Writer at amd.com
Tue Jul 13 14:11:07 PDT 2010


On Tue, Jul 13 2010, Gaetan Nadon <memsize at videotron.ca> wrote:

> On Tue, 2010-07-13 at 22:52 +0300, Martin-Éric Racine wrote:
>
>     On Tue, Jul 13, 2010 at 10:48 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
>     > On Tue, 2010-07-13 at 20:47 +0300, Martin-Éric Racine wrote:
>     >
>     > 1) to transform the current check for 64-bit CPU to make it add -m32
>     > to CFLAGS if the build host is a 64-bit.
>     >
>     > > I had tried this compiler option a while ago:
>     > >
>     > > /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or
>     > > directory
>
>     That would be a sign that the 32-bit libraries are missing, unless
>     I'm mistaken.
>
> Correct. On my distro, the 32 bit libs aren't installed by
> default. That brings us back to a compile error for the unsuspecting
> builder/new comer. That's not an issue for a geode developer who
> wishes to use AMD64 as a developing platform.

Hmmm. I see a desire to build upstream Xorg from source and being an
unsuspecting builder/newcomer as mutually exclusive. While this
particular error message is a little opaque, the solution is straight
forward and only an apt-get/yum/YaST, etc. away. I think most developers
will have no trouble understanding that building 32-bit anything on a
64-bit platform requires at least a basic 32-bit development
environment. Once we have 32-bit builds working correctly on 64-bit
systems, it would be useful to add the above error to a FAQ (is there a
FAQ for xorg-driver-geode?) but what else can we do. Most (all?) Linux
distributions are packaged this way, with separate 64-bit and 32-bit
development environments. Even if we would prefer it another way, what
can we reasonably do about it?

Tim



More information about the Xorg-driver-geode mailing list