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