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 [EMAIL PROTECTED] http://mailman.laptop.org/mailman/listinfo/devel
