[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