On Tue, Jul 13 2010, Gaetan Nadon <[email protected]> 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 <[email protected]> > 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 _______________________________________________ Xorg-driver-geode mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-geode
