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

From ArchWiki
Jump to: navigation, search
(Recommended file placement is now /usr/lib/cross-*)
(Hows and whys)
Line 83: Line 83:
 
Why not installing into ''/opt''? There would be no need for fooling around with non-standard executable namings etc.?
 
Why not installing into ''/opt''? There would be no need for fooling around with non-standard executable namings etc.?
 
: Two reasons:
 
: Two reasons:
:: First, according to File Hierarchy Standard, these files just belong to ''/usr''. Period.
+
:: First, according to File Hierarchy Standard, these files just belong somwhere to ''/usr''. Period.
 
:: Second, installing into ''/opt'' is a last meassure when there is no other option.
 
:: Second, installing into ''/opt'' is a last meassure when there is no other option.
 
Binutils creates some ugly looking directories (architecture named) directly under ''/usr''!
 
: You need to manually specify '''tooldir''' during make (both with <code>make all</code> and <code>make install</code>).
 
<pre>make tooldir=/usr all || return 1
 
make tooldir=/usr DESTDIR=${pkgdir} install || return 1</pre>
 
  
 
What is that ''out-of-path executables'' thing?
 
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 <code>$PATH</code> to use "our" executables first is a very quick solution.
 
: 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 <code>$PATH</code> to use "our" executables first is a very quick solution.
 
: You would then run <code>PATH=/usr/bin/cross/<i>arch</i>/:$PATH make</code> instead of <code>make</code>.
 
: You would then run <code>PATH=/usr/bin/cross/<i>arch</i>/:$PATH make</code> instead of <code>make</code>.

Revision as of 18:51, 15 October 2009

Important

This page describes a proposal, not an accepted approach!

Package Naming

The package name shall be prefixed with the word cross-, followed by architecture name and the package name itself shall come at the end.

Thus, cross GCC for MIPS shall be cross-mips-gcc.


File Placement

To prevent file conflicts, place everything into /usr/lib/cross-<arch>. The only exception to this rule are executables, that shall be placed directly into /usr/bin/ (however, 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 GCC for MIPS. Things worth noticing are:

  • manually specifying where to find the as and ld binaries
  • usage of ${_pkgname} and ${_target} variables to make the code more readable
  • removal of the duplicated/conflicting files
# Contributor: Your name <your@email.somewhere.net>
pkgname=cross-mips-gcc
_pkgname=gcc
pkgver=4.3.2
pkgrel=2
pkgdesc="The GNU Compiler Collection for the MIPS architecture"
url="http://www.gnu.org/software/binutils/"
arch=('i686' 'x86_64')
license=('GPL')
depends=('mpfr' 'sh' 'cross-mips-binutils')
options=('!ccache' '!distcc' '!emptydirs' '!libtool' '!strip')
source=("ftp://ftp.gnu.org/gnu/gcc/gcc-${pkgver}/${_pkgname}-core-${pkgver}.tar.bz2")
md5sums=('dd8048b43d3d4e5595bcade47b9144c6')
_target="mipsel-linux-gnu"

build() {
	cd ${srcdir}/${_pkgname}-${pkgver}
	
	./configure \
		"--prefix=/usr" \
		"--libexecdir=/usr/lib" \
		"--program-prefix=${_target}-" \
		"--target=${_target}" \
		"--mandir=/usr/share/man" \
		--without-headers \
		--with-gnu-as --with-gnu-ld \
		--with-as=/usr/bin/${_target}-as \
		--with-ld=/usr/bin/${_target}-ld \
		--disable-nls --disable-multilib --disable-shared \
		--disable-libgcj --disable-threads --disable-tls \
		--enable-languages=c || return 1
	
	make all-gcc || return 1
	
	make DESTDIR=${pkgdir} install-gcc || return 1
	
	msg "Removing duplicit files..."
	# remove these files as they are already in the system
	# (with native gcc)
	rm -Rf ${pkgdir}/usr/info
	rm -f ${pkgdir}/usr/lib/libiberty.a
	rm -Rf ${pkgdir}/usr/share/man
	rm -Rf ${pkgdir}/usr/share/info

	msg "Creating out-of-path executables..."
	# symlink executables to single directory with no-arch-prefix name
	mkdir -p ${pkgdir}/usr/bin/cross/${_target}/;
	cd ${pkgdir}/usr/bin/cross/${_target}/;
	for bin in ${pkgdir}/usr/bin/${_target}-*; do
		bbin=`basename "$bin"`;
		ln -s "/usr/bin/${bbin}" `echo "$bbin" | sed "s#^${_target}-##"`;
	done
}


Hows and whys

Why not installing into /opt? There would be no need for fooling around with non-standard executable namings etc.?

Two reasons:
First, according to File Hierarchy Standard, these files just belong somwhere to /usr. Period.
Second, installing into /opt is a last meassure 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/bin/cross/arch/:$PATH make instead of make.