GNU配置binutils，gcc和glib的选项

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

我正在尝试在我的debian-testing机器上构建一个替代编译套件(对不起,真正的问题实际上是在底部)。

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.

从技术上讲,这是一个“交叉编译”,因为我需要在另一台机器上使用这个工具链,但硬件兼容(x86_64-unknown-linux-gnu)所以我不需要为构建/主机/目标差异而烦恼。

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.

另一方面,我需要担心前缀/ sysroot,因为我不能安装在任何标准位置(更准确地说:我可以安装在任何地方,因为我有root访问权限,但我不应该);这给我留下了我的$ HOME,一些完全不标准的地方(例如:/ usr / local / my / toolchain)或一些半标准的地方(例如:/ opt)。在任何情况下,我都需要做一些事情来使编译能够在这些地方找到包含和库以及运行时链接器来查找所需的.so。

My requirements are:

我的要求是:

1. I have a running Linux that shouln't be messed with.

我有一个运行的Linux,不应该被搞砸。

2. This system does not have a "C" compiler.

该系统没有“C”编译器。

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.

所谓的linux是基于BusyBox的,所以我需要大量的实用程序来进行任何严格的编译,包括make,sed,awk,...,在编译器本身旁边。

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.

我很乐意在/ opt中填充我的扩充工具链,但这不是必需的;任何地方都可以,只要它可以由多个用户访问,我希望不要在$ 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).

   它只有32位(我的系统是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.

   某些程序无法编译,因为提供的库有32/64不匹配。

我知道“optware”,我安装了它,它确实有效......直到某一点。不幸的是:它真的很老软件只有32位(我的系统是Linux syno0 3.2.40#5004 SMP Thu Nov 6 15:26:44 CST 2014 x86_64 GNU / Linux)。某些程序无法编译,因为提供的库有32/64不匹配。

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

完成所有这些练习的真正动机是我需要安装一些必须在那里运行的应用程序所需的perl模块,并从cpan安装它们我需要一个本机编译器(当然还有其他东西)。

7. Similar arguments about a Ruby-on-rails application I should port there.

关于Ruby-on-rails应用程序的类似论点我应该移植到那里。

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

如果可能的话,我应该尝试使用/ lib:/ lib64中的“本机”库:/ usr / lib:/ usr / lib64:/ usr / lib32(“static”。一个libs不可用)。

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

我从处理器的可用工具链中准备一个自定义tarball,将其重新定位到/ opt,在其sysroot中填充所需的应用程序并使用以下内容进行编译:CPPFLAGS =“ - I / opt / include”和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.

这使我能够构建几乎所有“LFS风格”的东西,但它相当容易出错且只有64位。

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.

我似乎明白应该可以通过仔细混合--prefix, - with-sysroot, - with-native-system-header-dir, - enable-multilib和他们的朋友来自动化所有这些。

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.

出于某种原因,我试图准确理解它们应该如何使用和失败。我没有找到任何详尽的文档和GCC安装文档中的信息让我感到困惑。

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.

我假设重新编译Binutils和GCC是强制性的,可能不需要Glib;其他任何东西都可以在目标上重新编译“本机”。

TiA ZioByte

1 个解决方案

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

在非标准位置安装工具链后,需要使用LIBRARY_PATH和C_INCLUDE_PATH或CPLUS_INCLUDE_PATH为GCC正确设置环境(可能是系统范围的)。

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)

  在每次重定位时,将GCC路径添加到PATH环境变量中。并在busybox配置文件中创建别名(通常是/ 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.

  为您的工具链启动器脚本创建将计算路径,但您应该使用直接路径启动它,在启动构建过程时设置它,或者当然您可以将其位置添加到PATH环境变量。

  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.

  最可靠和符合人体工程学的方法 - 创建安装/卸载脚本,将正确解压缩和设置环境,重新定位工具链,您将从一个前缀卸载并安装到另一个前缀。如果你的debian测试系统上有dpkg,.deb包是最好的选择。

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

提示*为了获得更好的稳定性,您应该隔离工具链,并在前缀Linux Kernel header和Glib中安装