Hi,
On 10/12/2011 10:56 AM, ext Carsten Munk wrote:
2011/10/11 Eero Tamminen<[email protected]>:
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.
Marius has many good points, especially on bootstrapping vs. normal
build acceleration mode and I completely agree with his post.
SB2 supports different build acceleration modes and Marius' only
complaint for SB2 is that it was used inappropriately in Maemo SDK+,
not that there's any fundamental issue with SB2 itself though...
I slightly disagree that this approach breaks more packages than SB1
did :)
Sorry, it was intentionally slightly provocative. :-)
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' ;)
I think that needs a bit of debate.
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 is what I really don't like. Repository or rootstrap shouldn't
be "a random" mix of packages for different architectures.
This meant that we were always sure, that the
accelerated X86 binary on ARM side would match the original ARM
binary's source version.
This approach is no different from what is recommended for SB2
currently (on the mailing list, it's documentation is quite lacking).
Except that:
- you mix in the same place x86 & ARM packages
- because of above, you need to rename acceleration packages
- your x86 binaries are in different path so that they don't
conflict with target ones
-> you can leak wrong paths to generated scripts like SB1 does
- your control is on the package level, you cannot have more
fine-grained control. That for example prevents accelerating
more packages
- you cannot enforce/detect issues when acceleration packages cross
the lines they shouldn't[1].
?
[1] This is what newer SB2 versions have been paying some attention.
Latest added for example some support for detecting/controlling
whether builds access internet as some packages like to "call home"
when they're built...
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].
This you can of course do with SB2 and it's also the recommendation.
There just isn't OBS type of automation for getting the packages
because managing the packages isn't SB's role, that's what things
like OBS are for.
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.
If latest SB2 gets proper RPM support, would there be interest to
try that with OBS?
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.
It has. And its default rules don't try to accelerate quite as
much as first versions did as that caused some issues.
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
Thanks for the links!
How up to date the last two pages are e.g. in regards to what binaries
are accelerated? They mention armv5 toolchains...
- Eero
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
