Skip to content
Anonymous1157 edited this page Jun 20, 2017 · 3 revisions

These are some miscellaneous notes I've collected that could be helpful. Some of them explain weird configure command choices.

Directory assumptions

The build directory and source code can be most anywhere. On my system, I did all of the work in a directory tree under $HOME/.local/src/cross with subdirectories like src and build to control the chaos. That meant I did most builds from $HOME/.local/src/cross/build/pkgname and called configure scripts as ../../src/pkgname-version/configure.

The target directory where the cross compiler(s) will be installed can be most anywhere. On my system, this was $HOME/.local/share/cross. There is no reason why they couldn't be installed in a system-wide directory, but that requires root access.

Add the bin directory to your path!

Don't forget to add the bin directory to your path! You can run this in the current shell to use it for the current session, or add it to a file like .bashrc to save the change and always have these toolchains available.

export PATH="$HOME/.local/share/cross/bin:$PATH"

Why combined trees?

Most instructions to build cross-compilers found elsewhere on the Internet don't even mention the possibility of a combined tree build and just build Binutils, GCC, GDB, and Newlib individually. There's nothing strictly wrong with that. However, the GNU toolchain uses lots of supporting libraries like ZLib, GNU Readline, and libiberty, which seperate builds cannot share and must recompile individually as each part of the toolchain needs them. It also becomes harder to build the components with consistent configure flags. For compiler targets that use Newlib, you can start the entire toolchain and libc building in one step and come back later to find it ready to install.

Combined trees do have a downside. The components being combined need to have been released within a few weeks of each other at most so that the master copy of the build system is compatible with all of them. Sometimes versions that work fine when built separately have compilation failures when built in a combined tree. I have observed mysterious and hard-to-understand failures compiling Binutils if the version of GCC combined "on top of it" has too new a build system.

Why the extra LDFLAGS?

It's possible for the toolchains to fail to build with strange errors about not being able to find a working C compiler, which, when investigated, comes down to not finding a library you're sure you've built and installed and is right there in the install directory. In order to avoid this, nearly everything for the host system is built with a linker flag to check the install directory first.

When building libraries, this is appended to configure arguments:

LDFLAGS="-Wl,-rpath=$HOME/.local/share/cross/lib"

Building GCC toolchains works a little differently, so this is appended:

--with-{stage1,boot}-ldflags="-Wl,-rpath=$HOME/.local/share/cross/lib"
Clone this wiki locally