Difference between revisions of "Cross-compiling tools package guidelines"

From ArchWiki
Jump to: navigation, search
m (Building a Cross Compiler)
(Remove gentoo crossdev link. Its page does not contain matrix anymore.)
 
(14 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
[[Category:Package development]]
 
[[Category:Package development]]
{{Package Guidelines}}
+
{{Package guidelines}}
  
 
__TOC__
 
__TOC__
  
{{Tip|As alternative for creation of cross-compiler packages you could use [http://crosstool-ng.org/  crosstool-ng] and create you own toolchain in fully automated way. crosstool-ng can be found on {{AUR|crosstool-ng}}}}.
+
{{Tip|As alternative for creation of cross-compiler packages you could use [http://crosstool-ng.org/  crosstool-ng] and create you own toolchain in fully automated way. crosstool-ng can be found on {{AUR|crosstool-ng}}.}}
  
 
== Important note ==
 
== Important note ==
This page describes new way of doing things, inspired by follwing packages in {{Ic|[community]}}:
+
This page describes the new way of doing things, inspired by the following packages in {{Ic|[community]}}:
*{{Pkg|mingw32-gcc}} and other packages from {{Ic|mingw32-*}} series
+
*{{Pkg|mingw-w64-gcc}} and other packages from {{Ic|mingw-w64-*}} series
*{{Pkg|arm-elf-gcc-base}} and other packages from {{Ic|arm-elf-*}} series
+
*{{Pkg|arm-none-eabi-gcc}} and other packages from {{Ic|arm-none-eabi-*}} series
*{{Pkg|arm-wince-cegcc-gcc}} and other packages from {{Ic|arm-wince-cegcc-*}} series
+
*{{AUR|arm-wince-cegcc-gcc}}{{Broken package link|{{aur-mirror|arm-wince-cegcc-gcc}}}} and other packages from {{Ic|arm-wince-cegcc-*}} series
  
 
== Version compatibility ==
 
== Version compatibility ==
{{Warning|Using incompatible version of packages for toolchain compilation leads to inevitable failures. By default consider '''all''' versions incompatible.}}
+
{{Warning|Using incompatible versions of packages for toolchain compilation leads to inevitable failures. By default consider '''all''' versions incompatible.}}
  
Following strategies allows to select compatible vesions of gcc, binutils, kernel and C library:
+
The following strategies allows you to select compatible vesions of gcc, binutils, kernel and C library:
 
*General rules:
 
*General rules:
**there is correlation between gcc and binutils releases, use simultaneously released versions;
+
**there is a correlation between gcc and binutils releases, use simultaneously released versions;
 
**it is better to use latest kernel headers to compile libc but use {{Ic|--enable-kernel}} switch (specific to glibc, other C libraries may use different conventions) to enforce work on older kernels;
 
**it is better to use latest kernel headers to compile libc but use {{Ic|--enable-kernel}} switch (specific to glibc, other C libraries may use different conventions) to enforce work on older kernels;
 
*[[Official repositories]]: you may have to apply additional fixes and hacks, but versions used by Arch Linux (or it's architecture-specific forks) most probably can be made to work together;
 
*[[Official repositories]]: you may have to apply additional fixes and hacks, but versions used by Arch Linux (or it's architecture-specific forks) most probably can be made to work together;
 
*Software documentation: all GNU software have {{Ic|README}} and {{Ic|NEWS}} files, documenting things like minimal required versions of dependencies;
 
*Software documentation: all GNU software have {{Ic|README}} and {{Ic|NEWS}} files, documenting things like minimal required versions of dependencies;
 
*Other distributions: they too do cross-compilation
 
*Other distributions: they too do cross-compilation
**Gentoo crossdev [http://en.gentoo-wiki.com/wiki/Crossdev#Known%20Workingn%20Architecturen%20Matrix lists] some working combinations.
 
 
*http://cross-lfs.org covers steps, necessary for building cross-compiler and mentions somewhat up-to-date versions of dependencies.
 
*http://cross-lfs.org covers steps, necessary for building cross-compiler and mentions somewhat up-to-date versions of dependencies.
  
== Building a Cross Compiler ==
+
== Building a cross compiler ==
 
The general approach to building a cross compiler is:
 
The general approach to building a cross compiler is:
 
#binutils: Build a cross-binutils, which links and processes for the target architecture
 
#binutils: Build a cross-binutils, which links and processes for the target architecture
Line 42: Line 41:
 
The package name shall '''not''' be prefixed with the word {{Ic|cross-}} (it was previously proposed, but was not adopted in official packages, probably due to additional length of names), and shall consist of the package name, prefixed by [http://wiki.debian.org/Multiarch/Tuples GNU triplet] without vendor field or with "unknown" in vendor field; example: {{Ic|arm-linux-gnueabihf-gcc}}. If shorter naming convention exists (e.g. {{Ic|mips-gcc}}), it may be used, but this is not recommended.
 
The package name shall '''not''' be prefixed with the word {{Ic|cross-}} (it was previously proposed, but was not adopted in official packages, probably due to additional length of names), and shall consist of the package name, prefixed by [http://wiki.debian.org/Multiarch/Tuples GNU triplet] without vendor field or with "unknown" in vendor field; example: {{Ic|arm-linux-gnueabihf-gcc}}. If shorter naming convention exists (e.g. {{Ic|mips-gcc}}), it may be used, but this is not recommended.
  
== File Placement ==
+
== File placement ==
 
Latest versions of gcc and binutils use non-conflicting paths for sysroot and libraries. Executables shall be placed into {{Ic|/usr/bin/}}, to prevent conflicts here, prefix all of them with architecture name.
 
Latest versions of gcc and binutils use non-conflicting paths for sysroot and libraries. Executables shall be placed into {{Ic|/usr/bin/}}, to prevent conflicts here, prefix all of them with architecture name.
  
Line 69: Line 68:
  
 
_target=i686-pc-mingw32
 
_target=i686-pc-mingw32
_sysroot=/usr/lib/cross-${_target}
+
_sysroot=/usr/lib/${_target}
  
pkgname=cross-${_target}-binutils
+
pkgname=${_target}-binutils
 
_pkgname=binutils
 
_pkgname=binutils
 
pkgver=2.19.1
 
pkgver=2.19.1
Line 105: Line 104:
  
 
== Hows and whys ==
 
== Hows and whys ==
{{FAQ|question=
+
 
Why not installing into {{Ic|/opt}}?
+
=== Why not installing into {{Ic|/opt}}? ===
|answer=
+
 
 
Two reasons:
 
Two reasons:
 
#First, according to File Hierarchy Standard, these files just belong somewhere to {{Ic|/usr}}. Period.
 
#First, according to File Hierarchy Standard, these files just belong somewhere to {{Ic|/usr}}. Period.
 
#Second, installing into {{Ic|/opt}} is a last measure when there is no other option.
 
#Second, installing into {{Ic|/opt}} is a last measure when there is no other option.
}}
 
  
{{FAQ|question=
+
=== What is that ''out-of-path executables'' thing? ===
What is that ''out-of-path executables'' thing?
+
 
|answer=
+
 
This weird thing allows easier cross-compiling. Sometimes, project Makefiles do not use {{Ic|CC}} & co. variables and instead use '''gcc''' directly. If you just want to try to cross-compile such project, editing the Makefile could be a very lengthy operation. However, changing the {{Ic|$PATH}} to use "our" executables first is a very quick solution. You would then run {{Ic|1=PATH=/usr/''arch''/bin/:$PATH make}} instead of {{Ic|make}}.
 
This weird thing allows easier cross-compiling. Sometimes, project Makefiles do not use {{Ic|CC}} & co. variables and instead use '''gcc''' directly. If you just want to try to cross-compile such project, editing the Makefile could be a very lengthy operation. However, changing the {{Ic|$PATH}} to use "our" executables first is a very quick solution. You would then run {{Ic|1=PATH=/usr/''arch''/bin/:$PATH make}} instead of {{Ic|make}}.
}}
 
 
  
 
== Troubleshooting ==
 
== Troubleshooting ==
{{FAQ|question=
+
 
What to do if compilation fails without clear message?
+
=== What to do if compilation fails without clear message? ===
|answer=
+
 
 
For error, occurred during running {{Ic|configure}}, read {{Ic|$srcdir/''pkgname''-build/config.log}}. For error, occurred during compilation, scroll console log up or search for word "error".
 
For error, occurred during running {{Ic|configure}}, read {{Ic|$srcdir/''pkgname''-build/config.log}}. For error, occurred during compilation, scroll console log up or search for word "error".
}}
 
  
{{FAQ|question=
+
=== What does this error [error message] means? ===
What does this error [error message] means?
+
 
|answer=
+
 
Most probably you made some of non-obvious errors:
 
Most probably you made some of non-obvious errors:
 
* Too many or too few configuration flags. Try to use already proven set of flags.
 
* Too many or too few configuration flags. Try to use already proven set of flags.
Line 137: Line 130:
 
* sysroot does nor yet has kernel/libc headers.
 
* sysroot does nor yet has kernel/libc headers.
 
* If google-fu does not help, immediately abandon current configuration and try more stable/proven one.
 
* If google-fu does not help, immediately abandon current configuration and try more stable/proven one.
}}
 
  
{{FAQ|question=
+
=== Why do files get installed in wrong places? ===
Why do files get installed in wrong places?
+
 
|answer=
+
 
Various methods of running generic {{Ic|make install}} line results in different results. For example, some make targets may not provide {{Ic|DESTDIR}} support and instead require {{Ic|install_root}} usage. The same for {{Ic|tooldir}}, {{Ic|prefix}} and other similar arguments. Sometimes providing parameters as arguments instead of environment variables, e.g
 
Various methods of running generic {{Ic|make install}} line results in different results. For example, some make targets may not provide {{Ic|DESTDIR}} support and instead require {{Ic|install_root}} usage. The same for {{Ic|tooldir}}, {{Ic|prefix}} and other similar arguments. Sometimes providing parameters as arguments instead of environment variables, e.g
 
  ./configure CC=arm-elf-gcc
 
  ./configure CC=arm-elf-gcc
Line 147: Line 138:
 
  CC=arm-elf-gcc ./configure
 
  CC=arm-elf-gcc ./configure
 
and vice versa may result in different outcomes (often caused by recursive self-invocation of configure/make).
 
and vice versa may result in different outcomes (often caused by recursive self-invocation of configure/make).
}}
 
  
 
== See also ==
 
== See also ==
 
http://wiki.osdev.org/GCC_Cross-Compiler
 
http://wiki.osdev.org/GCC_Cross-Compiler

Latest revision as of 07:07, 30 March 2016

Package creation guidelines

CLRCrossEclipseFree PascalGNOMEGoHaskellJavaKDEKernelLispMinGWNonfreeOCamlPerlPHPPythonRubyVCSWebWine

Tip: As alternative for creation of cross-compiler packages you could use crosstool-ng and create you own toolchain in fully automated way. crosstool-ng can be found on crosstool-ngAUR.

Important note

This page describes the new way of doing things, inspired by the following packages in [community]:

Version compatibility

Warning: Using incompatible versions of packages for toolchain compilation leads to inevitable failures. By default consider all versions incompatible.

The following strategies allows you to select compatible vesions of gcc, binutils, kernel and C library:

  • General rules:
    • there is a correlation between gcc and binutils releases, use simultaneously released versions;
    • it is better to use latest kernel headers to compile libc but use --enable-kernel switch (specific to glibc, other C libraries may use different conventions) to enforce work on older kernels;
  • Official repositories: you may have to apply additional fixes and hacks, but versions used by Arch Linux (or it's architecture-specific forks) most probably can be made to work together;
  • Software documentation: all GNU software have README and NEWS files, documenting things like minimal required versions of dependencies;
  • Other distributions: they too do cross-compilation
  • http://cross-lfs.org covers steps, necessary for building cross-compiler and mentions somewhat up-to-date versions of dependencies.

Building a cross compiler

The general approach to building a cross compiler is:

  1. binutils: Build a cross-binutils, which links and processes for the target architecture
  2. headers: Install a set of C library and kernel headers for the target architecture
    1. use linux-api-headers as reference and pass ARCH=target-architecture to make
    2. create libc headers package (process for Glibc is described here)
  3. gcc-stage-1: Build a basic (stage 1) gcc cross-compiler. This will be used to compile the C library. It will be unable to build almost anything else (because it can't link against the C library it doesn't have).
  4. libc: Build the cross-compiled C library (using the stage 1 cross compiler).
  5. gcc-stage-2: Build a full (stage 2) C cross-compiler

The source of the headers and libc will vary across platforms.

Tip: Exact procedure varies greatly, depending on your needs. For example, if you want to create a "clone" of an Arch Linux system with the same versions of kernel and glibc, you can skip building headers and pass --with-build-sysroot=/ to configure.

Package naming

The package name shall not be prefixed with the word cross- (it was previously proposed, but was not adopted in official packages, probably due to additional length of names), and shall consist of the package name, prefixed by GNU triplet without vendor field or with "unknown" in vendor field; example: arm-linux-gnueabihf-gcc. If shorter naming convention exists (e.g. mips-gcc), it may be used, but this is not recommended.

File placement

Latest versions of gcc and binutils use non-conflicting paths for sysroot and libraries. Executables shall be placed into /usr/bin/, to prevent conflicts here, prefix all of them with architecture name.

Typically, ./configure would have at least following parameters:

_target=<your-target> # e.g. i686-pc-mingw32
_sysroot=/usr/lib/${_target}
...
./configure \
    --prefix=${_sysroot} --sysroot=${_sysroot} \
    --bindir=/usr/bin

Example

This is PKGBUILD for binutils for MinGW. Things worth noticing are:

  • specifying root directory of the cross-environment
  • usage of ${_pkgname}, ${_target} and ${_sysroot} variables to make the code more readable
  • removal of the duplicated/conflicting files
# Maintainer: Allan McRae <allan@archlinux.org>

# cross toolchain build order: binutils, headers, gcc (pass 1), w32api, mingwrt, gcc (pass 2)

_target=i686-pc-mingw32
_sysroot=/usr/lib/${_target}

pkgname=${_target}-binutils
_pkgname=binutils
pkgver=2.19.1
pkgrel=1
pkgdesc="MinGW Windows binutils"
arch=('i686' 'x86_64')
url="http://www.gnu.org/software/binutils/"
license=('GPL')
depends=('glibc>=2.10.1' 'zlib')
options=('!libtool' '!distcc' '!ccache')
source=(http://ftp.gnu.org/gnu/${_pkgname}/${_pkgname}-${pkgver}.tar.bz2)
md5sums=('09a8c5821a2dfdbb20665bc0bd680791')

build() {
  cd ${srcdir}/${_pkgname}-${pkgver}
  mkdir binutils-build && cd binutils-build

  ../configure --prefix=${_sysroot} --bindir=/usr/bin \
    --with-sysroot=${_sysroot} \
    --build=$CHOST --host=$CHOST --target=${_target} \
    --with-gcc --with-gnu-as --with-gnu-ld \
    --enable-shared --without-included-gettext \
    --disable-nls --disable-debug --disable-win32-registry
  make
  make DESTDIR=${pkgdir}/ install
  
  # clean-up cross compiler root
  rm -r ${pkgdir}/${_sysroot}/{info,man}
}
Note: During cross-toolchain building always execute configure and make commands from dedicated directory (so-called out-of-tree compilation) and remove whole src directory after slightest change in PKGBUILD.

Hows and whys

Why not installing into /opt?

Two reasons:

  1. First, according to File Hierarchy Standard, these files just belong somewhere to /usr. Period.
  2. Second, installing into /opt is a last measure when there is no other option.

What is that out-of-path executables thing?

This weird thing allows easier cross-compiling. Sometimes, project Makefiles do not use CC & co. variables and instead use gcc directly. If you just want to try to cross-compile such project, editing the Makefile could be a very lengthy operation. However, changing the $PATH to use "our" executables first is a very quick solution. You would then run PATH=/usr/arch/bin/:$PATH make instead of make.

Troubleshooting

What to do if compilation fails without clear message?

For error, occurred during running configure, read $srcdir/pkgname-build/config.log. For error, occurred during compilation, scroll console log up or search for word "error".

What does this error [error message] means?

Most probably you made some of non-obvious errors:

  • Too many or too few configuration flags. Try to use already proven set of flags.
  • Dependencies are corrupted. For example misplaced or missing binutils files may result in cryptic error during gcc configuration.
  • You did not add export CFLAGS="" to your build() function (see bug 25672 in GCC Bugzilla).
  • Some --prefix/--with-sysroot combination may require directories to be writable (non-obvious from clfs guides).
  • sysroot does nor yet has kernel/libc headers.
  • If google-fu does not help, immediately abandon current configuration and try more stable/proven one.

Why do files get installed in wrong places?

Various methods of running generic make install line results in different results. For example, some make targets may not provide DESTDIR support and instead require install_root usage. The same for tooldir, prefix and other similar arguments. Sometimes providing parameters as arguments instead of environment variables, e.g

./configure CC=arm-elf-gcc

instead of

CC=arm-elf-gcc ./configure

and vice versa may result in different outcomes (often caused by recursive self-invocation of configure/make).

See also

http://wiki.osdev.org/GCC_Cross-Compiler