GNU configure options for binutils, gcc & glib

Question

I am trying to build an alternative compilation suite on my debian-testing machine (sorry, real question is actually at bottom).

Technically it is a "cross-compilation" because I need to use this toolchain on another machine, but hardware is compatible (x86_64-unknown-linux-gnu) so I don't need to bother about build/host/target differencies.

On the other hand I do need to worry about prefix/sysroot because I cannot install in any standard location (to be more precise: I could install anywhere, since I have root access there, but I shouldn't); This leaves me with my $HOME, some completely non-standard place (e.g.: /usr/local/my/toolchain) or some semi-standard (e.g.: /opt) place. In any case I will need to do something to enable compilation to find includes and libs in such places and runtime linker to find needed .so.

My requirements are:

1. I have a running Linux that shouln't be messed with.
2. This system does not have a "C" compiler.
3. Said linux is BusyBox-based, so I will need a substantial amount of utilities to do any serious compiling there, including make, sed, awk, ..., beside the compiler proper.
4. I would be happy to stuff my augmented toolchain in /opt, but that is not a requirement; any place is ok as long as it's accessible by more than a single user, I would like ot avoid installing in $HOME.
5. I am aware of "optware", I installed it and it does work... up to a point. Unfortunately:
   • It's really old software
   • it's only 32bit (my system is Linux syno0 3.2.40 #5004 SMP Thu Nov 6 15:26:44 CST 2014 x86_64 GNU/Linux).
   • Some programs won't compile because provided libs have 32/64 mismatch.
6. Real motivation to do all this exercise is I need to install some perl modules needed for one application that will have to run there and to install them from cpan I need a native compiler (and other stuff, of course).
7. Similar arguments about a Ruby-on-rails application I should port there.
8. If at all possible I should try to use the "native" libs in /lib:/lib64:/usr/lib:/usr/lib64:/usr/lib32 ("static" .a libs are not available).

I had a limited success preparing a custom tarball from an available toolchain for my processor, relocating it to /opt, stuffing needed apps in its sysroot and compiling with: CPPFLAGS="-I/opt/include" and LDFLAGS="-L/opt/lib -Wl,-rpath -Wl,/opt/lib".

This enables me to build almost everything "LFS-style", but it's rather error-prone and 64-bit-only.

I seem to understand it should possible to automatize all this by a careful mix of --prefix, --with-sysroot, --with-native-system-header-dir, --enable-multilib and their friends.

I tried to understand exactly how they should be used and failed, for a reason or another. I didn't find any exhaustive documentation and information in GCC instalation docs are confusing me.

Can someone, please, give me a recipe to build this toolchain? Any pointer to in-depth documentation welcome, but I suspect some tutoring will be necessary.

I assume recompilation of Binutils and GCC is mandatory, Glib is probably not needed; anything else can be recompiled "native" on target.

TiA ZioByte

Answer 1

After installing your toolchain in nonstandard places you need to set environment(maybe system-wide) correctly for GCC using LIBRARY_PATH and C_INCLUDE_PATHor CPLUS_INCLUDE_PATH.

Environment Variables Affecting GCC

I see three ways to automate setting path variables for your relocatable toolchain:

• on every relocation adding your GCC path to your PATH environment variable. And create alias in your busybox profile (usually /etc/profile)

  alias example:

  alias gcc='TOOLCHAIN_PREFIX=$(which gcc | rev | cut -d"/" -f3-10 |rev); \
             LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
             C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ gcc'
  

• creating for your toolchain launcher-script that will calculate pathes, but you'll should launch it with direct path, setting it when you launch build process, or of course you can add its location to PATH environment varaible.

  script example

  #!/bin/sh
  TOOLCHAIN_PREFIX=$(echo $0 | rev | cut -d"/" -f3-10 |rev);
  LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
      C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ \
      $TOOLCHAIN_PREFIX/bin/gcc-4.*
  

• The most reliable and ergonomic way — create install/uninstall script that will unpack and set environment correctly, to relocate toolchain you will uninstall from it from one prefix and install to another. If you have dpkg on your debian-testing system, .deb package is best choice.

I can see no way to set environment fully automatically. But we can reduce it to setting just one path — path of toolchain.

HINT* For better stability you should isolate your toolchain and also install in your prefix Linux Kernel headers and Glib