New subject: [opensuse-buildservice] cross-compilation (in OBS) - success report

28 Nov 2007

      Hallo.

I just tried to analyze the cost of the cross-compilation support in
OpenSUSE BS.

This long mail attempts to describe steps to this goal:

Numbers mean steps needed for solution.
Letters mean alternative solutions.
+ means (probably) mandatory step to make initial support

+1. Provide cross compilation tools.
 2. Prepare build environment.
+2.1 Prepare host environment.
 2.1.1 RPM level problems.
 2.2 Prepare target environment.
+2.2a sysroot
 2.2b target root map
 2.2a.1 RPM level problems.
+2.2a.1a Use rpm --noscripts.
 2.2a.1b Use virtual host for installation.
 3. Compilation problems.
 3a Native compilation in the virtual build host
+3b Cross-compilation
+3b.1 Bootstrapping
 3b.2 QA
+3b.3 Provide cache
+3b.4 RPM level problems
+3b.5 Fix packages
 3b.6 Fix autotools
 4. Fix remaining problem

Details:

1. Provide cross compilation tools.
Thanks top huge amount of work on gcc, it's trivial. Setting additional
configure switches to gcc and binutils will provide needed support for
as many targets as we want.

2. Prepare build environment.

2.1 Prepare host environment.
Trivial. Build environment consists from the compilation environment,
typically including cross-compiler, cross-binutils, language tools
(bison, flex,...), documentation processing tools etc.

2.1.1 RPM level problems: I am not sure, whether RPM discriminates
between Build Target Requires and Build Host Requires. If not, then we
should provide sufficient host environment for all packages.

2.2 Prepare target environment.
There are two approaches to prepare target environment:

2.2a sysroot
The whole target system image resides in one sub-directory.
Pros:
Easy to create using existing tools.
Some tools already have support for it (gcc, binutils).
sysroot can be used by virtual hosts and emulators directly.
Cons:
If you want to build more targets at once, it is a waste of resources.

2.2b target root map
Target root map splits target build system to more sub-directories - one
contains architecture independent packages, another contains
architecture dependent packages, and others can contain target system or
even device specific. AFAIK, target root map is currently used only by
OpenEmbedded projects.
Pros:
Easy to build for many targets at one recycling most of files.
Cons:
Set-up needs special tools, no chance to use existing tools.
Needs special tools to operate with compiler and linker paths.

I can imagine, that 2.2a would be much easier to create using existing
tools for creating chroot.

2.2a.1 RPM level problems:
RPM has no support for discriminating between scriptlets usable in a
cross-platform way (and using relative paths) and scriptlets creating
platform specific data. There is also no discrimination between
scriptlets required to use this package for compilation and to use this
package for runtime.

There are only two obvious work-arounds:

2.2a.1a Use rpm --noscripts. Nobody knows, what will happen, but one
could expect, that the package will be still usable for compilation.
It is obvious, that the target sysroot will not be usable by emulators
directly.

2.2a.1b Use virtual host for installation. You will get a perfect image
of the target system, but it is expected to be much slower.

Obviously 2.2a.1a is the only acceptable solution.

Other (minor) problems would require fixes to discriminate between
CFLAGS (for target) and HOST_CFLAGS (for build host).

3. Compilation problems

Nowadays, in the age of autotools, simple changing of paths to basic
tools (CC, LD,...) works surprisingly well. But well, there are still
two ways to compile packages:

3a Native compilation in the virtual build host

If you have a running virtual host, it is a very simple way, which makes
no cross-compilation problems. On the other hand, it has a very poor
performance.

3b Cross-compilation

Cross compilation provides a full performance compilation, but needs a
support from each part of the toolchain, which may bring some problems.

But as we can see, there are several toolchains providing complete or
nearly complete build using only cross-compilation:
http://www.openembedded.org/
https://dev.openwrt.org/

3b.1 Bootstrapping

Bootstrapping would require initial steps to provide initial base
system. It is a bit specific - to compile glibc, you don't need target
compiler. But this step needs rpm level solution to ignore selected
BuildRequires.

3b.2 QA

It works well, but not perfectly. Many checks provide bad values and
running QA checks rejecting traces of sysroot paths in the result seems
to be mandatory.

3b.3 Provide cache values

configure provide an option to use cached values. This feature (with
required infrastructure to share these caches) allows to run complicated
autoconf checks once on the target system and recycle cache variables
for cross-compilation builds.

Autotools provide support for system-wide check cache.

3b.4 RPM level problems

Cross compilation would require changes in particular RPM scripts. For
example AutoReqProv may need to be changed.

3b.5 Fix packages

Particular packages may not support cross compilation well. The main
reasons are:
- Missing AC_CACHE_VAL wrapper disables to provide correct check result.
- Poorly written check.
- Attempt to use target binary in the host system without defining it.
- (Not autotools) toolchain is not ready for cross compilation

3b.6 Fix autotools

Autotools has a nice cross compilation support yet. Most checks are
written in a very pure way and work well for cross compilation.
But autotools has no support for sysroot and checks, which could benefit
from it does not yet work. For example AC_CHECK_FILE could work well
with sysroot support.

4. Fix remaining problem

Here we have to provide solution for remaining problems, which cannot be
provided by a cross compiler. It might include special actions like
providing initial values of system caches, locales etc.

It might or might not be critical for packaging itself.

Having a working virtual build host would be a generic solution for all
remaining problems.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarská 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

[opensuse-buildservice] cross-compilation in OBS - analysis

Stanislav Brabec

Adrian Schröter

Stanislav Brabec

Ulrich Hecht

Ulrich Hecht

Bernhard Walle

Stanislav Brabec

Ulrich Hecht

Stanislav Brabec

Ulrich Hecht

Stanislav Brabec

Ulrich Hecht

Stanislav Brabec

Richard Guenther

Stanislav Brabec

Petr Cerny

tags

participants (6)