Warning - lots of detail below. On 22/12/13 23:29, Marko Koschak wrote: > Hi Matze > > On So, 2013-12-22 at 21:50 +0100, christopher.l...@thurweb.ch wrote: >> The SDK Build Engine is a little bit more tricky. >> >> Once you SSH in, zypper is available, but if you zypper at that level, >> all you are doing is adding stuff to the operating system. >> >> Within this VM is SB2, which is the Build Engine itself. Others on >> this mailist are much better qualified than me to tell you more about >> it. > > If you are familiar with the term chroot (change-root) then you could > thing of SB2 (Scratchbox2) just as an chroot environment running armv7hl > emulated code (through qemu) where you actually build your source rpm > package.
This is pretty much correct but not quite complete. I mentioned earlier that I used the term "build engine" to describe the vbox VM :) Inside there are a number of tools, systems and datasets which are used to do the building and sb2 is part of that toolset; it needs a rootfs for the target architecture, hence the word 'target' which floats around. Actually a target is more specific than that - a target represents a versioned set of devel headers/libraries/tools. (Pendantic note : our use of sb2 doesn't yet provide a 'perfect' versioned target environment but we're working on it) > SB2 comes from the "legacy" of cross-compiling. I think it's better to say "sb2 avoids the user-side complications of cross-compiling but benefits from the performance boost." > The problem > with cross-compiling is that you need to tell your compiler not to use > the host (x86) tools and libs for compiling but the equivalent tools and > libs from the target (armv7hl) system. There are multiple approaches to > overcome that. One is to tell the compiler (via e.g. configure, > makefile,...) where to find that stuff or you don't tell the compiler > that (less work to create a makefile that cross-compiles too) but alter > your environment that the compiler "thinks" it is running on the target > (armv7hl) system itself. This is what SB2 actually does. That is very > useful if you want to compile just any "normal" rpm package (from the > linux userland stack) without adapting it to the target architecture. Yes - sb2 responds like a native ARM system to quite a deep level. > (In detail SB2 is not a "full" chroot system, but it uses fakeroot which > enables SB2 to use host tools for speed up compilation instead of > running arm binaries in slow emulation mode. It's quite some time ago I > used SB2 but I hope I got it right and you got a rough idea... :) This isn't quite right. It doesn't use fakeroot as such. What it does is intercept system calls (using LD_PRELOAD) and, very efficiently, translates filesystem access (using lua if you must know!) If you're using sb2 and you are in an ARM rootfs then when you access /usr/bin/myexecutable sb2 looks for the 'right' file to execute. First it considers that your target is in /srv/mer/target/jolla-arm so it has the option to look at /srv/mer/target/jolla-arm/usr/bin/myexecutable which is an ARM binary that could run using qemu. This would be the fallback location However it may see that file is in a list of 'accelerated' binaries. So it now looks in the 'host' filesystem (usually the host but more sophisticated solutions are available). So it runs the native /usr/bin/myexecutable - but it continues to intercept system calls. So if myexecutable open()s a /usr/share/mydata then sb2 translates that path to /srv/mer/target/jolla-arm/usr/share/mydata Now, for some special binaries - like gcc, ld etc we don't want to use the /usr/bin/gcc - we use an x86 version of gcc which emits ARM code. More docs here: https://maemo.gitorious.org/scratchbox2/scratchbox2/blobs/raw/2.3_development/docs/SB2_internals_1st_ed_20120425.pdf Also, you may find some help on setting up your own targets here: https://wiki.merproject.org/wiki/Platform_SDK_and_SB2 This follows on from: https://wiki.merproject.org/wiki/Platform_SDK note that the SDK Build Engine VM is essentially an installation of the Platform SDK inside a VM so you don't need another. So, yes, these are cross-compilers and cross-tools but the important thing is that the user just sees a very efficient "native" environment. HTH David PS Merry Christmas _______________________________________________ SailfishOS.org Devel mailing list
