[opensuse-buildservice] cross-compilation in OBS - analysis
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
On Wednesday 28 November 2007 15:06:11 wrote Stanislav Brabec:
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:
do you considered to add qemu support to the build script ? Just add another section where XEN code exist. In that case all software could get compiled "natively" on their architectures without changing the packages. Or is this not sufficiant in some cases ? bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Adrian Schröter píše v St 28. 11. 2007 v 15:44 +0100:
On Wednesday 28 November 2007 15:06:11 wrote Stanislav Brabec:
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:
do you considered to add qemu support to the build script ? Just add another section where XEN code exist.
In that case all software could get compiled "natively" on their architectures without changing the packages.
Or is this not sufficiant in some cases ?
Sufficient but slow. If cross compilation of a particular package works, it can save about 90% of compile time. And for example mentioned OpenWrt builds 100% of packages using cross-toolchain, OpenEmbedded build by cross-toolchain everything except locales. Locales take ~1 hours to build. The rest of the whole X image (kernel, glibc, xorg, tools, GPE cross compiled) builds 1.5 hours. (On 8x Xeon x86_64.) -- 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
On Wednesday 28 November 2007, Stanislav Brabec wrote:
And for example mentioned OpenWrt builds 100% of packages using cross-toolchain, OpenEmbedded build by cross-toolchain everything except locales.
Do not underestimate the complexity of preparing a large number of packages for cross-compilation just because it works on paper. In practice, it hardly ever does. You can expect to have to touch the majority of our packages, and when you do that you will find that autoconf is often more a part of the problem than of the solution. CU Uli -- Heute ist - Tag der Befreiung (in Albanien) - Tag der nationalen Einheit (in Vanuatu) - W. Tubmans Geburtstag (in Liberia) SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 29 November 2007, Ulrich Hecht wrote:
autoconf
Thinking about it, this should probably say libtool... CU Uli -- Heute ist - Tag der Befreiung (in Albanien) - Tag der nationalen Einheit (in Vanuatu) - W. Tubmans Geburtstag (in Liberia) SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Stanislav Brabec <sbrabec@suse.cz> [2007-11-28 15:51]:
And for example mentioned OpenWrt builds 100% of packages using cross-toolchain, OpenEmbedded build by cross-toolchain everything except locales.
Yes, and how much patches have they applied? Who maintains these patches here? Thanks, Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Bernhard Walle wrote:
* Stanislav Brabec <sbrabec@suse.cz> [2007-11-28 15:51]:
And for example mentioned OpenWrt builds 100% of packages using cross-toolchain, OpenEmbedded build by cross-toolchain everything except locales.
Yes, and how much patches have they applied? Who maintains these patches here?
Surprisingly, not so much. Most packages compile without any patches, other need correct config.cache values. You can look yourself: http://monotone.openembedded.org/ (branch org.openembedded.dev, directory packages, slow dynamically created page) https://svn.openwrt.org/openwrt/trunk/package/ -- 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
On Wednesday 28 November 2007, Stanislav Brabec wrote:
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.
Actually, all you need to do is to copy a QEMU userspace emulator into the sysroot and set up binfmt_misc appropriately, and the scripts should work just fine. There will of course be ways to break this, but usually pre/post scripts do not do anything complicated or expensive. CU Uli -- Heute ist - Tag der Befreiung (in Albanien) - Tag der nationalen Einheit (in Vanuatu) - W. Tubmans Geburtstag (in Liberia) SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Ulrich Hecht wrote:
On Wednesday 28 November 2007, Stanislav Brabec wrote:
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.
Actually, all you need to do is to copy a QEMU userspace emulator into the sysroot and set up binfmt_misc appropriately, and the scripts should work just fine. There will of course be ways to break this, but usually pre/post scripts do not do anything complicated or expensive.
It could work only for platforms, for which emulator exists. It will cost about 95% of power. If you will use native icecream hosts for parallel compilation, it will still cost about 80% of power (make has to run natively, linker will probably run natively as well. -- 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
On Friday 30 November 2007, Stanislav Brabec wrote:
Ulrich Hecht wrote:
Actually, all you need to do is to copy a QEMU userspace emulator into the sysroot and set up binfmt_misc appropriately, and the scripts should work just fine. There will of course be ways to break this, but usually pre/post scripts do not do anything complicated or expensive.
It could work only for platforms, for which emulator exists.
AXP (although that one is broken AFAIK), ARM (BE and LE), CRIS, i386, 68k, MIPS (BE and LE), PPC (32 and 64 bits), SH4, and SPARC (32 and 64 bits).
It will cost about 95% of power. If you will use native icecream hosts for parallel compilation, it will still cost about 80% of power (make has to run natively, linker will probably run natively as well.
This is not what I have been talking about at all. What I was getting at is that you seem to think it is not possible to install packages and running their pre/post scripts without moving the entire build into a (system) emulator. This is wrong, you just have to do what I described above, and you can set up your sysroot on any machine. How you build the packages has nothing to do with that. CU Uli -- Heute ist - Tag der Helden (in Philippinen) - Unabhängigkeitstag (in Barbados, Jemen) Heute ist ausserdem - St. Andreas-Tag (in Haiti) SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Ulrich Hecht píše v Pá 30. 11. 2007 v 17:34 +0100:
On Friday 30 November 2007, Stanislav Brabec wrote:
Ulrich Hecht wrote:
Actually, all you need to do is to copy a QEMU userspace emulator into the sysroot and set up binfmt_misc appropriately, and the scripts should work just fine. There will of course be ways to break this, but usually pre/post scripts do not do anything complicated or expensive.
It could work only for platforms, for which emulator exists.
AXP (although that one is broken AFAIK), ARM (BE and LE), CRIS, i386, 68k, MIPS (BE and LE), PPC (32 and 64 bits), SH4, and SPARC (32 and 64 bits).
It will cost about 95% of power. If you will use native icecream hosts for parallel compilation, it will still cost about 80% of power (make has to run natively, linker will probably run natively as well.
This is not what I have been talking about at all. What I was getting at is that you seem to think it is not possible to install packages and running their pre/post scripts without moving the entire build into a (system) emulator. This is wrong, you just have to do what I described above, and you can set up your sysroot on any machine. How you build the packages has nothing to do with that.
The question is: Is it required for cross-compilation? As far as I tested it, I found only one compile-time breakage: linux-kernel-headers did not create /usr/include/asm. I doubt there will be many such problems. Most caches and files created are required only for runtime. For example OE uses virtual machine only for very few tasks, e. g. compilation of locales. Second question is: How we would handle post/pre, if we will do it? Should we start the virtual engine and do complete RPM installation there, or install on native system, then resume virtual machine and run pre/post and suspend again? -- 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
On Friday 30 November 2007, Stanislav Brabec wrote:
Second question is: How we would handle post/pre, if we will do it? Should we start the virtual engine and do complete RPM installation there, or install on native system, then resume virtual machine and run pre/post and suspend again?
http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC2 There is no virtual machine involved in any of this. The QEMU user mode emulators simply allow you to run foreign binaries. CU Uli -- Heute ist - Tag der Helden (in Philippinen) - Unabhängigkeitstag (in Barbados, Jemen) Heute ist ausserdem - St. Andreas-Tag (in Haiti) SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Stanislav Brabec wrote:
I just tried to analyze the cost of the cross-compilation support in OpenSUSE BS.
I just experimentally cross-compiled several packages from the 10.3 sources. It is not so complicated as it seemed before, but I had to fight with many minor problems. I decided to build few simple powerpc RPM on x86_64 machine: package using ./configure: gzip package using %configure: lha package using make: jpeg2ps I did not test shared library package yet. It needs cross libtool package and I did not yet created it. 1. Prepare build system OpenSuSE does not provide full cross compiler package and I failed to compile my own. Hopefully, SuSE provides cross binutils and cross compilation support for icecream. I abused it, unpacked, added compiler libraries from the native powerpc build. Richard Guenther probably knows, how to build full cross compiler package. It should be trivial. Because i am not expert in Build Service, I built build environment manually in my live system, thinking how it is possible to do by the Build Service. Thinking about it and OBS, I can imagine two approaches: 1a. Install packages from BuildRequires for both host and target. Complicated and maybe superfluous. Most checks will not find them or fail anyway. 1b. Prepare large enough native tool set. It will include everything we would need for cross compilation: native compiler and binutils, cross compiler and binutils, language tools (sed, awk, bison,...), generator tools (docbook, help2man,...) This is a way used by existing cross compilation toolchains. This is easy to do: We could simply add it to the XEN OBS image and modify chroot preparation tools to use another directory - chroot/sysroot. 2. Prepare build environment This is a trivial task for the Build Service. I did it manually: mkdir -p /sysroot/var/lib/rpm rpm -r /sysroot --initdb rpm --noscripts -r /root/sysroot -Uhv /work/CDs/all/full-ppc/suse/ppc/{glibc,filesystem,glibc-devel,coreutils,pam,libacl,libattr,libxcrypt,libdb-4_5,cracklib,cracklib-dict-small,bash,libreadline5,ncurses,audit-libs,info,zlib,libbz2-1,libzio,perl,gzip,perl-base,fillup,grep,sed,gdbm,diffutils}.rpm /work/CDs/all/full-ppc/suse/noarch/linux-kernel-headers.rpm rpm -Uhv /work/CDs/all/full-x86_64/suse/x86_64/{gcc42,gcc42-ada,libada42,cpp42,libgcc42,libmudflap42,libgomp42,gcc-ada,gcc}.rpm Compilation failure found only one trivial compile-critical breakage caused by --noscripts. Easy to fix. ln -s asm-powerpc /sysroot/usr/include/asm 3. Cross compilation Basically it works, but need to pay attention to it in the spec files. It means: - Run testsuite only for native build. - Never use gcc and ld directly, but use proper variables. I used following command line. Depending on toolchain used, it may vary (and it will be different for sure with a real cross compiler instead of my hacks): PATH=/opt/cross/bin:$PATH CC="gcc --sysroot=/sysroot" LD="gcc --sysroot=/sysroot" AS=powerpc-linux-as RANLIB=powerpc-linux-ranlib AR=powerpc-linux-ar STRIP=powerpc-linux-strip rpmbuild -ba --target=ppc-suse-linux *.spec (LD should probably have a different value) Problems discovered: Package with %configure: rpm provides --target command line argument, which is intended to cross compile. But it generates by mistake %configure for native compilation of cross compiler. One liner fix in /usr/lib/rpm/macros: --build=%{_target_platform} Packages with ./configure: Now I hacked the spec and added needed args: --host=x86_64-suse-linux --build=powerpc-suse-linux-gnu --target=powerpc-suse-linux-gnu But I am nearly sure that playing a bit with CONFIG_SITE would prevent this requirements. Package with make: spec file has to provide needed flags explicitly. One line change: make to make CC="$CC" LD="$LD" General problems of configure: AC_CHECK_FILE have no idea about sysroot and one has to provide cache values. It should be improvable on auttools level: http://idea.opensuse.org/content/ideas/design-and-implement-sysroot-support-... Some other checks can not have any idea about sysroot and target system by principle. One has to provide cache values. I guess it should be possible to generate such cache both per package and globally (maybe better, it is platform specific). And we are complete. Package build, installs and runs on powerpc. 4. Fix remaining problem As I wrote above, some spec files has to be changed to do things more carefully and many packages has to be fixed. But this example shows, that cross compilation is an usable way to make packages. -- 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
On Fri, 30 Nov 2007, Stanislav Brabec wrote:
Stanislav Brabec wrote:
I just tried to analyze the cost of the cross-compilation support in OpenSUSE BS.
I just experimentally cross-compiled several packages from the 10.3 sources. It is not so complicated as it seemed before, but I had to fight with many minor problems.
First - thanks for experimenting with this - something I have wanted to do for a long time.
Richard Guenther probably knows, how to build full cross compiler package. It should be trivial.
Haha - you think so ;) Any target that uses glibc is non-trivial to build a cross-compiler for. At least if you need to bootstrap the target, if you are fine with re-packaging the target native glibc package as a cross-glibc package it will be a lot easier. See the CrossToolchain:sh4 build-service project for an example how to set up a bootstrapable glibc target. Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Richard Guenther wrote:
On Fri, 30 Nov 2007, Stanislav Brabec wrote:
Richard Guenther probably knows, how to build full cross compiler package. It should be trivial.
Haha - you think so ;) Any target that uses glibc is non-trivial to build a cross-compiler for. At least if you need to bootstrap the target, if you are fine with re-packaging the target native glibc package as a cross-glibc package it will be a lot easier. See the CrossToolchain:sh4 build-service project for an example how to set up a bootstrapable glibc target.
I have been thinking about something much simpler - cross-gcc package with the binary in the path and with needed with required crt*.o files in /usr/lib/gcc/*-suse-linux/4.2.1. Having this, you can start to compile. Now we have only an icecream helper and one has to play with it to get a working cross compiler. First time compiling of glibc is another task. I can look at OpenEmbedded and OpenWrt, how they are bootstrapping the system. They are for sure starting with a clean table, having only native compiler for host platform and few other tools and a lot of sources. -- 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
Stanislav Brabec wrote:
First time compiling of glibc is another task.
I can look at OpenEmbedded and OpenWrt, how they are bootstrapping the system. They are for sure starting with a clean table, having only native compiler for host platform and few other tools and a lot of sources.
Maybe CLFS (http://trac.cross-lfs.org/) might be of interest for creating cross-compiling toolchain as well. Best regards Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (6)
-
Adrian Schröter -
Bernhard Walle -
Petr Cerny -
Richard Guenther -
Stanislav Brabec -
Ulrich Hecht