Blessing a C build environment.

[Don Hopkins]

One problem is that the sugar-jhbuild you get from git is using Python 
2.5, while the actual OLPC hardware is using Python 2.4.
If you want to build a Python module for the OLPC that depends on Python 
2.4, then you have to configure for 2.4 and build it outside of 
sugar-jhbuild and copy it into the right place on the OLPC.
(This is an issue with SWIG wrappers, which detects the version of 
Python you're building with and makes modules specific to that version.)

This Python 2.4 / Python 2.5 schism is only supposed to be temporary 
until the OLPC hardware runs the latest version of Fedora and everybody 
switches over to 2.5, but I don't know when that will be.

    -Don


Ryan C. Gordon wrote:
> 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.
>
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
>