UNPKG

arch-wiki-md-repo

Version:

All arch-wiki articles in markdown format, updated every two days.

183 lines (126 loc) 11 kB
**[Package creation guidelines](/index.php/Creating_packages "Creating packages")** * * * [CLR](/index.php/CLR_package_guidelines "CLR package guidelines") – <a class="mw-selflink selflink">Cross</a> – [Eclipse](/index.php/Eclipse_plugin_package_guidelines "Eclipse plugin package guidelines") – [Free Pascal](/index.php/Free_Pascal_package_guidelines "Free Pascal package guidelines") – [GNOME](/index.php/GNOME_package_guidelines "GNOME package guidelines") – [Go](/index.php/Go_package_guidelines "Go package guidelines") – [Haskell](/index.php/Haskell_package_guidelines "Haskell package guidelines") – [Java](/index.php/Java_package_guidelines "Java package guidelines") – [KDE](/index.php/KDE_package_guidelines "KDE package guidelines") – [Kernel](/index.php/Kernel_module_package_guidelines "Kernel module package guidelines") – [Lisp](/index.php/Lisp_package_guidelines "Lisp package guidelines") – [MinGW](/index.php/MinGW_package_guidelines "MinGW package guidelines") – [Node.js](/index.php/Node.js_package_guidelines "Node.js package guidelines") – [Nonfree](/index.php/Nonfree_applications_package_guidelines "Nonfree applications package guidelines") – [OCaml](/index.php/OCaml_package_guidelines "OCaml package guidelines") – [Perl](/index.php/Perl_package_guidelines "Perl package guidelines") – [PHP](/index.php/PHP_package_guidelines "PHP package guidelines") – [Python](/index.php/Python_package_guidelines "Python package guidelines") – [Ruby](/index.php/Ruby_Gem_package_guidelines "Ruby Gem package guidelines") – [VCS](/index.php/VCS_package_guidelines "VCS package guidelines") – [Web](/index.php/Web_application_package_guidelines "Web application package guidelines") – [Wine](/index.php/Wine_package_guidelines "Wine package guidelines") ## Contents * [1 Important note](#Important_note) * [2 Version compatibility](#Version_compatibility) * [3 Building a cross compiler](#Building_a_cross_compiler) * [4 Package naming](#Package_naming) * [5 File placement](#File_placement) * [6 Example](#Example) * [7 Hows and whys](#Hows_and_whys) * [7.1 Why not installing into /opt?](#Why_not_installing_into_.2Fopt.3F) * [7.2 What is that *out-of-path executables* thing?](#What_is_that_out-of-path_executables_thing.3F) * [8 Troubleshooting](#Troubleshooting) * [8.1 What to do if compilation fails without clear message?](#What_to_do_if_compilation_fails_without_clear_message.3F) * [8.2 What does this error [error message] means?](#What_does_this_error_.5Berror_message.5D_means.3F) * [8.3 Why do files get installed in wrong places?](#Why_do_files_get_installed_in_wrong_places.3F) * [9 See also](#See_also) **Tip:** As alternative for creation of cross-compiler packages you could use [crosstool-ng](http://crosstool-ng.org/) and create you own toolchain in fully automated way. crosstool-ng can be found on [crosstool-ng](https://aur.archlinux.org/packages/crosstool-ng/). ## Important note This page describes the new way of doing things, inspired by the following packages in `[community]`: * [mingw-w64-gcc](https://aur.archlinux.org/packages/mingw-w64-gcc/) and other packages from `mingw-w64-*` series * [arm-none-eabi-gcc](https://www.archlinux.org/packages/?name=arm-none-eabi-gcc) and other packages from `arm-none-eabi-*` series * [arm-wince-cegcc-gcc](https://aur.archlinux.org/packages/arm-wince-cegcc-gcc/) and other packages from `arm-wince-cegcc-*` series ## 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](/index.php/Official_repositories "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://clfs.org](http://clfs.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](https://www.archlinux.org/packages/?name=linux-api-headers) as reference and pass `ARCH=*target-architecture*` to **make** 2. create libc headers package (process for Glibc is described [here](http://sources.redhat.com/ml/crossgcc/2003-06/msg00170.html)) 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](https://wiki.debian.org/Multiarch/Tuples "debian:Multiarch/Tuples") 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](/index.php/PKGBUILD "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](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=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](http://wiki.osdev.org/GCC_Cross-Compiler)