Cross compiling arch linux

An Endless Xploration..

..to be more human every single day in this hopefully meaningful life.

Wednesday, August 17, 2016

Cross Compiling Windows Application and DLLs in (Arch) Linux

Cross compiling 32-bit and 64-bit Windows application in Linux is much easier these days than in the past. Thanks to the Mingw-w64 project. It’s even a little more easier in Arch Linux because most of what you need—including extensive amount of libraries—are already in AUR. For starter, install the cross compiler: https://www.archlinux.org/packages/community/x86_64/mingw-w64-gcc/. Then you can continue to install all other stuff (libraries and their dependencies) that you need. In most cases, you can just build and install the package by using the PKGBUILD file from AUR directly (via: cd $; makepkg -sri ). However, in some cases, you need to make adjustment(s) to the PKGBUILD file.

• Opensource projects that uses CMAKE build system, need to use the mingw-w64-specific cmake (look at the example PKGBUILD for cmake below).
• You need to set the include path to the cross compiler toolchain environment include path, not the host include path.

• Opensource projects that uses autotools build system, need to use the mingw-w64-specific configure script (look at the example PKGBUILD for configure below).
• In some cases, you need to «fool» the libtool script to pass the «dynamic/static library integrity» check. You don’t need to be afraid with this step because you could always use Linux file utility to verify the compiler output along with wine before testing/using it in real Windows installation.

You can clone the files required to «cross build» popt library at: https://bitbucket.org/pinczakko/cross_mingw-w64-popt.

Hopefully, this is useful for those developing Windows application in Linux. Post a Comment

Источник

Cross-compiling tools package guidelines

This page describes how to create packages for cross-compiler toolchains. Another method to cross-compile makes use of distcc on mixed architectures. See Distcc#Cross compiling with distcc.

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-ng .

Important note

This page describes the new way of doing things, inspired by the following packages:

• mingw-w64-gcc and other packages from mingw-w64-* series
• arm-none-eabi-gcc and other packages from arm-none-eabi-* series
• 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 versions 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;

  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)

     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 _sysroot=/usr/lib/$ . ./configure \ --prefix=$ \ --sysroot=$ \ --bindir=/usr/bin

     where your_target can be, e.g., «i686-pc-mingw32».

     Example

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

     • specifying root directory of the cross-environment
     • usage of $ , $ and $ variables to make the code more readable
     • removal of the duplicated/conflicting files

     # Maintainer: Allan McRae # cross toolchain build order: binutils, headers, gcc (pass 1), w32api, mingwrt, gcc (pass 2) _target=i686-pc-mingw32 _sysroot=/usr/lib/$ pkgname=$=2.10.1' 'zlib') options=('!libtool' '!distcc' '!ccache') source=(http://ftp.gnu.org/gnu/$/$.tar.bz2) md5sums=('09a8c5821a2dfdbb20665bc0bd680791') build() < cd $/$ mkdir binutils-build && cd binutils-build ../configure --prefix=$ --bindir=/usr/bin \ --with-sysroot=$ \ --build=$CHOST --host=$CHOST --target=$ \ --with-gcc --with-gnu-as --with-gnu-ld \ --enable-shared --without-included-gettext \ --disable-nls --disable-debug --disable-win32-registry make make DESTDIR=$/ install # clean-up cross compiler root rm -r $/$/ >

     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

     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

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

     See also

     Источник