Hi, 2011/10/11 Eero Tamminen <eero.tammi...@nokia.com>: > As to cross-building in OBS, I would recommend it to adopt SB2 as > what I've understood of its current cross-compilation solution looks > like an incomplete re-implementation of SB1 i.e. either much slower > or causing much more issues with builds.
Just pitching in with some information on the OBS cross building, just to clear up the differences - I've used both SB1 & SB2 including the deepest hells of both and know the weaknesses / strengths of those vs our current way of doing those in OBS. I also did a blog piece ages ago on the same topic[2] - Marius Vollmer's thoughts in [3] also reflects our way of thinking. I slightly disagree that this approach breaks more packages than SB1 did :) If there is packages that do break with this method, let us know, those of us who were/are in MeeGo ARM are still around in #meego-arm and in #mer on freenode IRC. So, as you know, OBS is a package builder tool, when it wants to build a package, it dumps in packages that are build dependencies for the source package into the chroot, including packages that are needed to build packages in general (as specified in project configuration, see [1]) and installs them into the chroot, first setting up a base system that can install RPM packages (Preinstall/Runscripts) and then the rest (Required:) For ARM (or other archs), it can either build straight on a ARM build worker, or, as we prefer, to run it like SB1 and SB2 does, by dumping in a qemu-arm (qemu binary emulation) into the chroot, running it on top of x86 and setting up binfmt_misc to utilize the qemu-arm static binary when an ARM binary is encountered by the kernel. When this was working, statistics were done to identify where there could be a benefit of accelerating certain binaries by making them X86 specific. The approach was simple: to make a 'fast' ARM build machine without the disadvantages of Scratchbox1 (fairly static toolset, difficult to maintain). - as well as not touching so much that would cause things to differ too much as if the build was native, such as emulating perl. And 'scratchbox done right' ;) To avoid the trap of the static toolset, it was chosen to take the existing x86-built binaries in OBS, build-dep on them and simply (through OBS methods) export them from the X86 build to the ARM build scheduler, replacing the ARM binaries in place with X86 binaries, which had been rewritten to use a different rpath [4, also documents cross toolchain method]. This meant that we were always sure, that the accelerated X86 binary on ARM side would match the original ARM binary's source version. It also meant, that when you did a local OBS build, you would gain same accelerated binaries as part of the chroot generated locally without having to install a seperate SDK/cross compilers. This approach showed an immense speedup in package build speed. Through additional methods, it was possible to export sysroots/glibc from ARM to X86 and hence we were able to create cross compilers that exactly matched the source code of the gcc package. See [4] for more information on that as well as [5]. The plan is to continue evolving and developing this approach in the open as part of Mer, we have a seperate small project called Crosshelpers that contain these bits and pieces. Hopefully it'll be useful for Tizen ARM too. We feel it's given us quite some strength and it's being less maintaining than doing it with SB2 seems to have been, except for minor improvements cross our setup has been stable. Some of us in "old" Mer explored SB2 as an approach back in 2008 but didn't find it working properly enough at that time - it may have stablized a lot since. With regards to a SDK point of view, the idea was originally in "old" Mer that you could actually utilize your X86 install of Mer as a working development development area as it worked fine in a virtual machine. And then only build for ARM when you have the 'fast' machine working, using a oneliner to build using OBS. That approach didn't work in MeeGo because of slow VM/non-working VM solutions and well, the fact that most people didn't have SSSE3. Even with OBS's 'build' package, it's possible to do non-OBS builds against a repository, though. I feel that this part was undermaintained and underresourced in MeeGo SDK. If you want more information, feel free to ask in this thread or in #meego-arm or #mer on irc.freenode.net [1] http://monster.tspre.org:2080/project/prjconf?project=Core%3Ai586 [2] http://mer-project.blogspot.com/2009/08/debconf-thoughts-part-two-on-cross.html [3] http://mariusv.wordpress.com/2008/12/07/the-cardinal-sin-of-scratchbox-a-backhanded-stab-at-the-maemo-sdk-and-the-promise-of-a-pot-of-gold/ [4] http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/CrossToolchain_Components [5] http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/CrossToolchain_Background BR Carsten Munk _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
