Blessing a C build environment.

[Ryan C. Gordon]

This is possibly an already-covered discussion topic, but I couldn't 
find anything in the wiki or email archives, and IRC offered several 
different opinions on the "correct" approach to building C code for the 
system.

There doesn't appear to be an official build environment for the laptops.

This isn't really an issue for Python code, since you put your text 
files that comprise your scripts into a bundle and go, more or less, but 
for C development, this is probably something worth clarifying. Even 
though the whole system is meant to be Free Software, it will still need 
to be diligent about binary compatibility, both for third parties and 
the official software stack.

Having spent many years fighting with these sorts of issues on desktop 
Linux, I wanted to note a few points:

- jhbuild-sugar is nice, but for people working on their own Activities 
and not the core system, it's not really that useful. Being able to 
build everything from scratch is also dangerous; for example, I might 
accidentally build with a different ABI, due to CFLAGS or gcc changes. 
jhbuild-sugar doesn't rebuild glibc or xlib (at least, build-base didn't 
here), so you end up linking against something that's probably mostly 
compatible with the libraries on the actual laptop, but maybe not. 
jhbuild-sugar doesn't seem to bootstrap a compiler, either, which means 
that you could end up targeting the wrong processor or introducing a 
subtle dependency (e.g.: libstdc++.so.23 or whatnot) or a big one 
(OpenGL) that works on my homespun Sugar environment but not ship on the 
  shipping units.
- Likewise for headers...I'm reminded of a version of math.h with buggy 
inline asm that broke Ogg Vorbis at one point, or libFLAC, which 
couldn't go a month without breaking their stable interfaces for awhile 
there. Or xlib, which seems to be a stable API until you find that 
_XData32 is a symbol that header macros force into your binary, but only 
on some platforms...The list goes on. There's just a big quantity of 
unknowns across "modern" x86 Linux distros...most are harmless, all are 
subtle, but they're all a risk. I'd rather use the same headers for all 
system components that ship on the box than what happens to be on my 
system when I build.
- If I want to test on the real hardware, I don't want to spend an hour 
building Mozilla in "jhbuild-sugar build-base". I want to use the exact 
mozilla libs that ship on the box, built by an expert, and the headers 
that were used to build them, which are better downloaded from an 
authoritative source than reconstructed. The rest is just wasted CPU and 
developer time while jhbuild-sugar churns, if I'm not interested in 
building my own desktop Sugar environment. Likewise, even without 
hardware for testing, I should be testing against an actual version of 
the shipping software in an emulator and not the Sugar environment I 
built myself.
- I get the impression from several people that generally, "all you have 
to do" is target a Fedora Core 6 system and you're roughly where the 
laptop is in terms of headers and libraries. Being a zealot like 
everyone else, I'd like to use "my" distro and my CPU arch, instead of 
using Fedora Core/x86 as a build environment...as multi-core boxes 
become more common, it makes less sense to put Fedora into a vmware 
image and not be able to fully exploit, say, a quad-core opteron system 
and "make -j4" when building. Also, Fedora and OLPC should be able to 
move separately (if, for example, one had wanted NPTL support in glibc 
and the other didn't, there'd be a problem brewing in terms of what to 
target), and OLPC shouldn't have to worry about a future Fedora update 
changing an important characteristic of the official disk image's build 
box, undetected.

Ok, so I'm talking myself blue here...here's what I think would be nice:

- Simplest approach: A tarball with just the files needed to build for 
the laptop: in the simplest form, this would basically be /lib, 
/usr/lib, etc from the machine, plus the headers used, and a Fedora 
Core-compatible toolchain (gcc, ld, etc). A developer can download, 
unpack, and chroot into it to get a "blessed" build environment on their 
workstation. Everything built in there will definitely work with the 
libraries on the laptop, and you'll know if you accidentally introduced 
an unavailable dependency, since it simply won't link. Those that need a 
toolchain for another arch (say, compiling your program for the laptop 
from a PowerPC machine, etc) can get some basic instructions on building 
a compatible cross-compiler (use THESE specific versions of gcc, 
binutils, etc).

- Extra credit: set up a cross-compiling environment right from the 
start (even if the "cross-compile" is from x86 to x86), and build every 
bit of the system core with it, including glibc, xlib, etc). This means 
that building the core system that eventually becomes the official disk 
image for the hardware is even freed from needing to be built on a 
specific distro or specific hardware...in some ways, jhbuild-sugar does 
this already, it just counts on some parts being supplied by the system 
and the arch being whatever...I was surprised that jhbuild-sugar didn't 
take this approach already. This approach removes the need for a chroot 
that the other solution requires, too. The toolchain can be easily 
rebuilt for whatever the workstation's architecture happens to be, even 
though it's always producing Geode-optimized x86 binaries with blessed, 
prebuilt libraries and headers.

Both solutions probably make smaller downloads than full "SDK" disk 
images for emulators, and don't require an emulator at all. Using Dan 
Kegel's excellent CrossTool (http://kegel.com/crosstool/), I've been 
using the cross-compiler method to target x86 Linux desktops with games 
like Unreal Tournament 2004, etc...this was quite a step up from 
building in an ancient version of Red Hat or Ubuntu in a vmware image to 
avoid glibc conflicts. The time spent on making this work well was worth 
every minute.

Just wanted to throw it out there as something that the OLPC project 
should probably seriously consider. Right now, there seems to be a LOT 
of uncertainty as to how to correctly and safely target the hardware as 
a C developer.

--ryan.