2005-12-06 18:05:20 +00:00
|
|
|
Setting up a cross compiler with Nix
|
|
|
|
|
|
|
|
"Cross compilation" means compiling a program on one machine for another
|
|
|
|
type of machine. A typical use of cross compilation is to compile programs
|
|
|
|
for embedded devices. These devices often don't have the computing power
|
|
|
|
and memory to compile programs natively.
|
|
|
|
|
|
|
|
For a fully working cross compiler the following are needed:
|
|
|
|
|
|
|
|
* cross binutils: assembler, archiver, linker, etcetera that understand
|
|
|
|
the format of the target system
|
|
|
|
|
|
|
|
* cross compiler: a compiler that can generate binary code and object files
|
|
|
|
for the target platform
|
|
|
|
|
|
|
|
* cross C library: a library to link object files with to create fully
|
|
|
|
functional programs
|
|
|
|
|
|
|
|
Cross compilers are difficult to set up. A lot of people report that they
|
|
|
|
cannot succeed in building a cross toolchain successfully. The answers
|
|
|
|
usually consist of "download this pre-built toolchain", which is equally
|
|
|
|
unhelpful.
|
|
|
|
|
|
|
|
A toolchain is set up in five steps:
|
|
|
|
|
|
|
|
1. build binutils to that can run on the host platform, but generate code
|
|
|
|
for the target platform
|
|
|
|
|
|
|
|
2. build Linux kernel headers for the target platform
|
|
|
|
|
|
|
|
3. build a minimal C only version of GCC, that can run on the host platform
|
|
|
|
and generate code for the target platform
|
|
|
|
|
|
|
|
4. build a C library for the target platform. This includes the dynamic
|
|
|
|
linker, C library, etc.
|
|
|
|
|
|
|
|
5. build a full GCC
|
|
|
|
|
|
|
|
****
|
|
|
|
NB:
|
|
|
|
|
|
|
|
Keep in mind that many programs are not very well suited for cross
|
|
|
|
compilation. Either they are not intended to run on other platforms,
|
2013-08-11 10:47:09 +00:00
|
|
|
because the code is highly platform specific, or the configuration process
|
2005-12-06 18:05:20 +00:00
|
|
|
is not written with cross compilation in mind.
|
|
|
|
|
|
|
|
Nix will not solve these problems for you!
|
|
|
|
***
|
|
|
|
|
|
|
|
This document describes to set up a cross compiler to generate code for
|
|
|
|
arm-linux with uClibc and runs on i686-linux. The "stdenv" used is the
|
|
|
|
default from the standard Nix packages collection.
|
|
|
|
|
|
|
|
Step 1: build binutils for arm-linux in the stdenv for i686-linux
|
|
|
|
|
|
|
|
---
|
|
|
|
{stdenv, fetchurl, noSysDirs}:
|
|
|
|
|
|
|
|
stdenv.mkDerivation {
|
|
|
|
name = "binutils-2.16.1-arm";
|
|
|
|
builder = ./builder.sh;
|
|
|
|
src = fetchurl {
|
2020-04-18 11:43:47 +00:00
|
|
|
url = "http://ftp.nluug.nl/gnu/binutils/binutils-2.16.1.tar.bz2";
|
doc: use sri hash syntax
The nixpkgs manual contains references to both sri hash and explicit
sha256 attributes. This is at best confusing to new users. Since the
final destination is exclusive use of sri hashes, see nixos/rfcs#131,
might as well push new users in that direction gently.
Notable exceptions to sri hash support are builtins.fetchTarball,
cataclysm-dda, coq, dockerTools.pullimage, elixir.override, and
fetchCrate. None, other than builtins.fetchTarball, are fundamentally
incompatible, but all currently accept explicit sha256 attributes as
input. Because adding backwards compatibility is out of scope for this
change, they have been left intact, but migration to sri format has been
made for any using old hash formats.
All hashes have been manually tested to be accurate, and updates were
only made for missing upstream artefacts or bugs.
2022-12-03 19:49:00 +00:00
|
|
|
hash = "sha256-14pv+YKrL3NyFwbnv9MoWsZHgEZk5+pHhuZtAfkcVsU=";
|
2005-12-06 18:05:20 +00:00
|
|
|
};
|
|
|
|
inherit noSysDirs;
|
2018-07-25 21:44:21 +00:00
|
|
|
configureFlags = [ "--target=arm-linux" ];
|
2005-12-06 18:05:20 +00:00
|
|
|
}
|
|
|
|
---
|
|
|
|
|
|
|
|
This will compile binutils that will run on i686-linux, but knows the
|
|
|
|
format used by arm-linux.
|
|
|
|
|
|
|
|
Step 2: build kernel headers for the target architecture
|
|
|
|
|
|
|
|
default.nix for kernel-headers-arm:
|
|
|
|
|
|
|
|
---
|
|
|
|
{stdenv, fetchurl}:
|
|
|
|
|
2018-08-20 19:11:29 +00:00
|
|
|
assert stdenv.buildPlatform.system == "i686-linux";
|
2005-12-06 18:05:20 +00:00
|
|
|
|
|
|
|
stdenv.mkDerivation {
|
2017-01-24 16:26:05 +00:00
|
|
|
name = "linux-headers-2.6.13.1-arm";
|
2005-12-06 18:05:20 +00:00
|
|
|
builder = ./builder.sh;
|
|
|
|
src = fetchurl {
|
2020-04-18 11:43:47 +00:00
|
|
|
url = "http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.bz2";
|
doc: use sri hash syntax
The nixpkgs manual contains references to both sri hash and explicit
sha256 attributes. This is at best confusing to new users. Since the
final destination is exclusive use of sri hashes, see nixos/rfcs#131,
might as well push new users in that direction gently.
Notable exceptions to sri hash support are builtins.fetchTarball,
cataclysm-dda, coq, dockerTools.pullimage, elixir.override, and
fetchCrate. None, other than builtins.fetchTarball, are fundamentally
incompatible, but all currently accept explicit sha256 attributes as
input. Because adding backwards compatibility is out of scope for this
change, they have been left intact, but migration to sri format has been
made for any using old hash formats.
All hashes have been manually tested to be accurate, and updates were
only made for missing upstream artefacts or bugs.
2022-12-03 19:49:00 +00:00
|
|
|
hash = "sha256-qtICDjfiA1HxWBrHqtB5DCv9s9/HyznKV1C6IxCrHYs=";
|
2005-12-06 18:05:20 +00:00
|
|
|
};
|
|
|
|
}
|
|
|
|
---
|
|
|
|
|
|
|
|
builder.sh for kernel-headers-arm:
|
|
|
|
|
|
|
|
---
|
|
|
|
source $stdenv/setup
|
|
|
|
|
|
|
|
|
|
|
|
buildPhase() {
|
|
|
|
make include/linux/version.h
|
|
|
|
}
|
|
|
|
|
|
|
|
buildPhase=buildPhase
|
|
|
|
|
|
|
|
|
|
|
|
installPhase() {
|
|
|
|
mkdir $out
|
|
|
|
mkdir $out/include
|
|
|
|
#cd $out/include
|
|
|
|
#ln -s asm-arm asm
|
|
|
|
make include/asm ARCH=arm
|
|
|
|
cp -prvd include/linux include/asm include/asm-arm include/asm-generic $out/include
|
|
|
|
echo -n > $out/include/linux/autoconf.h
|
|
|
|
}
|
|
|
|
|
|
|
|
installPhase=installPhase
|
|
|
|
|
|
|
|
|
|
|
|
genericBuild
|
|
|
|
---
|
|
|
|
|
|
|
|
Step 3: build a minimal GCC
|
|
|
|
|
|
|
|
Extra/different parameters include the target platform and the kernel
|
|
|
|
headers argument (this needs a major cleanup, as well as the name, it
|
|
|
|
needs to be different!). Profiled compilers are disabled. The tarball
|
|
|
|
used here is just gcc-core. For some reason it doesn't install nicely
|
|
|
|
if the whole tarball is used (or is this some braino on my side? -- AH).
|
|
|
|
|
|
|
|
Only C is used, because for other languages (such as C++) extra libraries
|
|
|
|
need to be compiled, for which libraries compiled for the target system
|
|
|
|
are needed.
|
|
|
|
|
2005-12-06 18:08:57 +00:00
|
|
|
There is a bit of evilness going on. The cross compiled utilities need
|
|
|
|
to be either copied to or be linked from the output tree of the compiler.
|
|
|
|
(Is this really true? Back this up with arguments! -- AH)
|
|
|
|
|
|
|
|
Symbolic links are not something we want inside the Nix store.
|
|
|
|
|
2005-12-06 18:05:20 +00:00
|
|
|
---
|
|
|
|
{ stdenv, fetchurl, noSysDirs
|
|
|
|
, langC ? true, langCC ? true, langF77 ? false
|
|
|
|
, profiledCompiler ? false
|
|
|
|
, binutilsArm
|
|
|
|
, kernelHeadersArm
|
|
|
|
}:
|
|
|
|
|
|
|
|
assert langC;
|
|
|
|
|
|
|
|
stdenv.mkDerivation {
|
|
|
|
name = "gcc-4.0.2-arm";
|
|
|
|
builder = ./builder.sh;
|
|
|
|
src = fetchurl {
|
doc: use sri hash syntax
The nixpkgs manual contains references to both sri hash and explicit
sha256 attributes. This is at best confusing to new users. Since the
final destination is exclusive use of sri hashes, see nixos/rfcs#131,
might as well push new users in that direction gently.
Notable exceptions to sri hash support are builtins.fetchTarball,
cataclysm-dda, coq, dockerTools.pullimage, elixir.override, and
fetchCrate. None, other than builtins.fetchTarball, are fundamentally
incompatible, but all currently accept explicit sha256 attributes as
input. Because adding backwards compatibility is out of scope for this
change, they have been left intact, but migration to sri format has been
made for any using old hash formats.
All hashes have been manually tested to be accurate, and updates were
only made for missing upstream artefacts or bugs.
2022-12-03 19:49:00 +00:00
|
|
|
url = "ftp://ftp.nluug.nl/pub/gnu/gcc/gcc-4.0.2/gcc-core-4.0.2.tar.bz2";
|
|
|
|
hash = "sha256-LANmXRS7/fN2zF5JUJVd8OjNA5aCDsGLQKhSpxWA3Qk=";
|
2005-12-06 18:05:20 +00:00
|
|
|
};
|
|
|
|
# !!! apply only if noSysDirs is set
|
|
|
|
patches = [./no-sys-dirs.patch ./gcc-inhibit.patch];
|
|
|
|
inherit noSysDirs langC langCC langF77 profiledCompiler;
|
|
|
|
buildInputs = [binutilsArm];
|
|
|
|
inherit kernelHeadersArm binutilsArm;
|
|
|
|
platform = "arm-linux";
|
|
|
|
}
|
|
|
|
---
|
|
|
|
|
2005-12-30 14:20:44 +00:00
|
|
|
The builder.sh for a cross-compiler. Note that the binutils are prefixed
|
|
|
|
with the architecture name, so arm-linux-ld instead of ld, etc. This is
|
|
|
|
necessary because when we cross-compile a lot of programs look for these
|
|
|
|
tools with these specific names. The standard gcc-wrapper does not take this
|
|
|
|
into account yet.
|
2005-12-06 18:05:20 +00:00
|
|
|
|
|
|
|
---
|
|
|
|
source $stdenv/setup
|
|
|
|
|
|
|
|
|
|
|
|
export NIX_FIXINC_DUMMY=$NIX_BUILD_TOP/dummy
|
|
|
|
mkdir $NIX_FIXINC_DUMMY
|
|
|
|
|
|
|
|
|
|
|
|
if test "$noSysDirs" = "1"; then
|
|
|
|
|
|
|
|
if test "$noSysDirs" = "1"; then
|
|
|
|
# Figure out what extra flags to pass to the gcc compilers
|
|
|
|
# being generated to make sure that they use our glibc.
|
2014-12-17 18:11:30 +00:00
|
|
|
if test -e $NIX_CC/nix-support/orig-glibc; then
|
|
|
|
glibc=$(cat $NIX_CC/nix-support/orig-glibc)
|
2005-12-06 18:05:20 +00:00
|
|
|
# Ugh. Copied from gcc-wrapper/builder.sh. We can't just
|
2014-12-17 18:11:30 +00:00
|
|
|
# source in $NIX_CC/nix-support/add-flags, since that
|
2005-12-06 18:05:20 +00:00
|
|
|
# would cause *this* GCC to be linked against the
|
|
|
|
# *previous* GCC. Need some more modularity there.
|
|
|
|
extraCFlags="-B$glibc/lib -isystem $glibc/include"
|
|
|
|
extraLDFlags="-B$glibc/lib -L$glibc/lib -Wl,-s \
|
|
|
|
-Wl,-dynamic-linker,$glibc/lib/ld-linux.so.2"
|
|
|
|
|
|
|
|
# Oh, what a hack. I should be shot for this.
|
|
|
|
# In stage 1, we should link against the previous GCC, but
|
|
|
|
# not afterwards. Otherwise we retain a dependency.
|
|
|
|
# However, ld-wrapper, which adds the linker flags for the
|
|
|
|
# previous GCC, is also used in stage 2/3. We can prevent
|
|
|
|
# it from adding them by NIX_GLIBC_FLAGS_SET, but then
|
|
|
|
# gcc-wrapper will also not add them, thereby causing
|
|
|
|
# stage 1 to fail. So we use a trick to only set the
|
|
|
|
# flags in gcc-wrapper.
|
|
|
|
hook=$(pwd)/ld-wrapper-hook
|
|
|
|
echo "NIX_GLIBC_FLAGS_SET=1" > $hook
|
|
|
|
export NIX_LD_WRAPPER_START_HOOK=$hook
|
|
|
|
fi
|
|
|
|
|
|
|
|
export NIX_EXTRA_CFLAGS=$extraCFlags
|
|
|
|
export NIX_EXTRA_LDFLAGS=$extraLDFlags
|
|
|
|
export CFLAGS=$extraCFlags
|
|
|
|
export CXXFLAGS=$extraCFlags
|
|
|
|
export LDFLAGS=$extraLDFlags
|
|
|
|
fi
|
|
|
|
|
|
|
|
else
|
|
|
|
patches=""
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
|
|
preConfigure=preConfigure
|
|
|
|
preConfigure() {
|
2020-07-31 05:06:53 +00:00
|
|
|
|
2005-12-06 18:05:20 +00:00
|
|
|
# Determine the frontends to build.
|
|
|
|
langs="c"
|
|
|
|
if test -n "$langCC"; then
|
|
|
|
langs="$langs,c++"
|
|
|
|
fi
|
|
|
|
if test -n "$langF77"; then
|
|
|
|
langs="$langs,f77"
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Cross compiler evilness
|
2012-01-18 20:16:00 +00:00
|
|
|
mkdir -p $out
|
|
|
|
mkdir -p $out/arm-linux
|
|
|
|
mkdir -p $out/arm-linux/bin
|
2005-12-06 18:05:20 +00:00
|
|
|
ln -s $binutilsArm/arm-linux/bin/as $out/arm-linux/bin/as
|
|
|
|
ln -s $binutilsArm/arm-linux/bin/ld $out/arm-linux/bin/ld
|
|
|
|
ln -s $binutilsArm/arm-linux/bin/ar $out/arm-linux/bin/ar
|
|
|
|
ln -s $binutilsArm/arm-linux/bin/ranlib $out/arm-linux/bin/ranlib
|
|
|
|
|
|
|
|
# Perform the build in a different directory.
|
|
|
|
mkdir ../build
|
|
|
|
cd ../build
|
|
|
|
|
|
|
|
configureScript=../$sourceRoot/configure
|
|
|
|
configureFlags="--enable-languages=$langs --target=$platform --disable-threads --disable-libmudflap --disable-shared --with-headers=$kernelHeadersArm/include --disable-multilib"
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
postInstall=postInstall
|
|
|
|
postInstall() {
|
|
|
|
# Remove precompiled headers for now. They are very big and
|
|
|
|
# probably not very useful yet.
|
|
|
|
find $out/include -name "*.gch" -exec rm -rf {} \; -prune
|
|
|
|
|
|
|
|
# Remove `fixincl' to prevent a retained dependency on the
|
|
|
|
# previous gcc.
|
|
|
|
rm -rf $out/libexec/gcc/*/*/install-tools
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
#if test -z "$profiledCompiler"; then
|
|
|
|
#makeFlags="bootstrap"
|
2020-07-31 05:06:53 +00:00
|
|
|
#else
|
2005-12-06 18:05:20 +00:00
|
|
|
#makeFlags="profiledbootstrap"
|
|
|
|
#fi
|
|
|
|
|
|
|
|
genericBuild
|
|
|
|
---
|
|
|
|
|
2005-12-06 18:08:57 +00:00
|
|
|
Step 4: build a C library for the target platform.
|
|
|
|
|
|
|
|
The previous steps are enough to compile a C library. In our case we take
|
|
|
|
uClibc. It's intended to be a small sized replacement for glibc. It is widely
|
|
|
|
used in embedded environments.
|
2005-12-06 21:47:41 +00:00
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
Step 5: Build a compiler to link with the newly built C library.
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
If we restrict the compiler to just C programs it is relatively easy,
|
|
|
|
since we only need to wrap the GCC we built in the previous step with all
|
|
|
|
the right tools and the right C library. Successfully compiled programs with
|
|
|
|
this compiler and verified to be working on a HP Jornada 820 running Linux
|
|
|
|
are "patch", "make" and "wget".
|
|
|
|
|
|
|
|
If we want to build C++ programs it gets a lot more difficult. GCC has a
|
2013-08-11 10:47:09 +00:00
|
|
|
three step compilation process. In the first step a simple compiler, called
|
2005-12-06 21:47:41 +00:00
|
|
|
xgcc, that can compile only C programs is built. With that compiler it
|
|
|
|
compiles itself two more times: one time to build a full compiler, and another
|
|
|
|
time to build a full compiler once again with the freshly built compiler from
|
|
|
|
step 2. In the second and third step support for C++ is compiled, if this
|
|
|
|
is configured.
|
|
|
|
|
|
|
|
One of the libraries that has to be built for C++ support step is libstdc++.
|
|
|
|
This library uses xgcc, even when cross compiling, since libstdc++ has to be
|
|
|
|
compiled for arm-linux.
|
|
|
|
|
|
|
|
One of the compiler flags that GCC uses for this compiler is called X_CFLAGS.
|
|
|
|
This is used by the Nix build process to set the dynamic linker, glibc
|
|
|
|
in the case of i686-linux using the default Nix packages collection.
|
|
|
|
|
2022-12-17 23:21:48 +00:00
|
|
|
Obviously, since we need to compile libstc++ for arm-linux with uClibc linking
|
2005-12-06 21:47:41 +00:00
|
|
|
will not be done correctly: you can't link object files built for arm-linux
|
|
|
|
with a glibc built for i686-linux.
|
|
|
|
|
|
|
|
Setting X_CFLAGS to use the uClibc libraries and dynamic linker will fail
|
|
|
|
too. Earlier on in the build process these flags are used to compile important
|
|
|
|
files like libgcc.a by the host system gcc, which does need to be linked
|
|
|
|
to glibc. To make this work correctly you will need to carefully juggle
|
|
|
|
with compilation flags. This is still work in progress for Nix.
|
2005-12-30 14:45:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
2013-08-11 10:47:09 +00:00
|
|
|
After successfully completing the whole toolchain you can start building
|
2005-12-30 14:45:27 +00:00
|
|
|
packages with the newly built tools. To make everything build correctly
|
|
|
|
you will need a stdenv for your target platform. Setting up this platform
|
|
|
|
will take some effort. Right now there is a very experimental setup for
|
|
|
|
arm-linux, which needs to be cleaned up before it is production ready.
|
|
|
|
|
|
|
|
Please note that many packages are not well suited for cross-compilation.
|
|
|
|
Even though the package itself might be very well portable often the
|
|
|
|
buildscripts are not. One thing that we have seen that causes frequent
|
|
|
|
build failures is the use of the LD variable. This is often set to 'ld'
|
|
|
|
and not $(CROSS)-ld.
|