I suspect what Michael really should be using is Scratchbox1, which is in fact quite capable of producing a filesystem that can go on the device.
Personally, I don't know what I'd do without it -- I currently build close to 200 open-source packages for my OS, and the idea of building them without the aid of Scratchbox1 is too gruesome to even think about :) One thing I would dearly love to see happen, though, is for Scratchbox1 get an updated libc. (I'd be willing to help with that effort, if such an effort were ever to be undertaken.) Diane On Tue, Apr 13, 2010 at 5:54 AM, Lauri T. Aarnio <[email protected]>wrote: > > On Apr 12, 2010, at 6:35 PM, ext Michael Turney wrote: > >> >> Pardon my ignorance, but if the modified filesystem cannot be copied back >> to the target, >> what problem does sb2 really solve, from a cross-development environment? >> > > Creating a file system image that can be installed to a device is really a > trivial problem. And there are several solutions for that; "debootstrap" is > maybe one the most widely known tools. Sb2 was not designed for that. > > However, cross-compiling - cross-building, actually - is not a trivial > problem in the linux world, because vast majority of the available OSS > programs have not been designed to be cross-compiled. > > In fact, many (most?) software packages require that they are built on a > system that is identical or really close to the target environment. Such > assumption is deeply buried into many software packages and to the tools, > too. > But compiling on a small embedded system is not very feasible.. and we'd > still like to use mainstream packages with minimal modifications. > > And that is what the scratchboxes were designed to solve: They are used to > create development environments, that are fairly compatible with the target > environment, so that we don't need to make changes to hundreds of software > packets to make them cross-compilation-aware. > > Creating a Linux cross-development environment which looks like a native > one might sound like an easy task to do, but it isn't. I'll try to explain > briefly why, based on our collective experiences on this field. > > Usually people are mistaken to think that only two or three things are > needed for successful cross-building: > > a) you need the target file system (which contains libraries, include > files, and also the tools that are needed: "make", autotools, etc) > > b) target CPU emulation is needed, and something like the user-mode Qemu > can be used to solve that . > > c) a cross-compiler is needed. Alternatively, the compiler can also be > executed within Qemu. > > Next, the over-simplified idea about cross-building says that you'll need > to combine all this within e.g chroot, and you're done. Wrong, > unfortunately. > > What is usually forgotten, is > > d) there are several ways how the development environment can be detected > (for example, the real CPU architecture of the build host), and various > tools use this information for build-time decisions. And even worse, such > details might be recorded to the produced binary packages. > > The result is, quite typically, that unless you pay attention to "d)" > above, your build might go thru without problems, but the results might be > crappy (perl extensions are famous examples of this). > > I'm not saying that everything would fail with the simple approach. It is > enough for many packages; but that might be even more dangerous because it > creates a false feeling of safety. > > The simple approach works in many cases, because there are tools that don't > care so much about the development environment and are safe to use. But the > opposite is also true: We have seen several tools that detect the > development environment, and then record features of it somewhere, thinking > that the execution environment would be the same. > > Once you have a complete distro that was cross-compiled, and some tool > somewhere did something nasty, finding out the problem is not so pleasant > experience anymore ;-) > > Another thing that I'm not saying is that the scratchboxes (1 or 2) would > be complete and would solve all such build-related problems. Very probably > they aren't; they just try to offer solutions to those problems that we have > analyzed and fixed. > > But we still think that it is easier to maintain this kind of environment > virtualization layers, than to make dozens or hundreds of changes to various > upper-level tools and packages. > > > I don't mean to sound glib, but sb2 was pushed on me as a solution to our >> cross development problem, >> not pushed by this mailing list, but by colleagues who had done some >> research. >> > > >> I really appreciate the above input, as it explains a lot of my >> frustration, but I have to >> wonder how people use sb2 in the wild? >> > > One example is the Maemo SDK+ project, which has used sb2 as a core > component. But it has been developed here, quite close to our sb2 > development, so I guess that it don't fall into the "in the wild" category. > > It would be nice to hear about other uses for this, too. > > > Lauri > > _______________________________________________ > Scratchbox-devel mailing list > [email protected] > http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel >
_______________________________________________ Scratchbox-devel mailing list [email protected] http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
