如何在tinycolinux32上安装tinycolinux64 kernel和toolchain

这篇文章主要讲解了"如何在tinycolinux32上安装tinycolinux64 kernel和toolchain"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"如何在tinycolinux32上安装tinycolinux64 kernel和toolchain"吧！

cross compile tinycolinux3.x 64

我们是在一台ubuntu14.04 64bit上的gcc485交叉编译出如下tinycolinux 3.x 64的(不要直接用tinycolinux上32位的gcc编译这个kernel):

参照《将tinycolinux以硬盘模式安装到云主机》一文的相似做法，我们从http://mirrors.163.com/tinycorelinux/3.x/release/src/kernel/下载64位的src和patch，打开virtualization中的virtio pci选项，编译进virtio block和network驱动，轻易在arch/x86/boot下得到bzimage，放到boot中启动。发现可以跟原有的rootfs一起正常启动。uname -m显示x86_64。file /boot/bzimage，显示x86 bootable kernel。猜这是因为在.config文件中同时开启了32和64支持，32位程序能运行在64位上，且原来的rootfs中的32位binutils和gcc未变。

如果把64位某linux的程序拷进来file它显示64bit elf，执行它会提示not found，这是因为它依赖的binutils ld没有，调用gcc -o helloworld.c -64m，提示unimplemented,这是因为3.x的rootfs是没有对应的GCC 64的。接下来需要cross compile一个：

在32 tinycolinux上boostrap compile gcc 4.4.3 64 三件套 for tinycolinux 3.x 64 target

一般地，GCC支持从高向低crosscompile，反过来要难一点。所以这里我们采取最简单的方法：从同版本的32位GCC bootstrap编译出同版本的GCC，采用本地的32位gcc bootstrap式cross compile出64位的gcc，不再使用外来cross compile的方案（直接那样也行）。当然这种方案是设想了tinycolinux上本来就存在GCC的事实基础上，如果追求更通用的实践目的，还是从外面的系统cross compile进来好。

这样产生出来的GCC仅是一个target到x86_64-pc-linux-gnu的gcc 443版本，因为在本机上构建，所以这个build和host都不变，为本机系统HOST，但是并不影响我们的工作继续，至于以后你要用这个GCC作鸡生蛋蛋生鸡的事，比如可以用这个再次自举GCC443到host也为443的版本inplace覆盖，这都是以后的事。GCC支持从32到64或反过来的交叉构建。

我们选用2.x repos的make.tcz(3.81版，为什么不使用3.x的make 382接下来会涉及到)和选用3.x repos的gcc443 32位(为什么不用4.x的gcc471：因为4.x后采用eglibc，在编译很多程序时会遇到重复定义错误，这个时候就应该想到是版本问题)，走从GCC443 32位编译出GCC443 64的方案，要保证系统绝对干净，否则可能会遇到各种坑(比如cant computer object file prefix,etc..)，介绍一下制作纯净tinycolinux系统的方法：

按《在硬盘上安装tinycolinux》的方法重新安装rootfs，相当于重装系统，除了保留第一步的64 bzimage在boot下引导不变，你可能需要额外安装openssh。然后下载3.x的toolchain并安装:

sudo unsquashfs -f -d / /tce/gccbase/gmp.tczsudo unsquashfs -f -d / /tce/gccbase/libmpc.tczsudo unsquashfs -f -d / /tce/gccbase/mpfr.tczsudo unsquashfs -f -d / /tce/gccbase/ppl.tczsudo unsquashfs -f -d / /tce/gccbase/cloog.tczsudo unsquashfs -f -d / /tce/gccbase/binutils.tczsudo unsquashfs -f -d / /tce/gccbase/bison.tczsudo unsquashfs -f -d / /tce/gccbase/diffutils.tczsudo unsquashfs -f -d / /tce/gccbase/file.tczsudo unsquashfs -f -d / /tce/gccbase/findutils.tczsudo unsquashfs -f -d / /tce/gccbase/flex.tczsudo unsquashfs -f -d / /tce/gccbase/gawk.tczsudo unsquashfs -f -d / /tce/gccbase/gcc.tczsudo unsquashfs -f -d / /tce/gccbase/grep.tczsudo unsquashfs -f -d / /tce/gccbase/m4.tczsudo unsquashfs -f -d / /tce/gccbase/make.tczsudo unsquashfs -f -d / /tce/gccbase/patch.tczsudo unsquashfs -f -d / /tce/gccbase/pkg-config.tczsudo unsquashfs -f -d / /tce/gccbase/sed.tczsudo unsquashfs -f -d / /tce/gccbase/base-dev.tcz#sudo unsquashfs -f -d / /tce/gccbase/gcc_libs.tcz#sudo unsquashfs -f -d / /tce/gccbase/linux-headers-2.6.33.3-tinycore.tcz

然后下载以下并准备，都解压到一个目录。

http://mirrors.163.com/tinycorelinux/3.x/release/src/compiletc_other/ (mpfr-2.4.2.tar.xz,gmp-4.3.2.tar.xz,binutils-2.20.tar.xz)

http://mirrors.163.com/tinycorelinux/3.x/release/src/glibc-2.11.1.tar.bz2 (不用2.11.1了，到ftp.glibc.gnu.com下载2.12.1，以后有用)

http://mirrors.163.com/tinycorelinux/3.x/release/src/gcc-4.4.3.tar.bz2(从GCC-4.3起，安装GCC将依赖于GMP-4.1以上版本和MPFR-2.3.2以上版本。如果将这两个软件包分别解压到GCC源码树的根目录下，并分别命名为"gmp"和"mpfr" )

1）首先编译binutils:

cd binutils-2.20 && sudo make b && cd bsudo ../configure --prefix=/usr/local/gcc443 --target=x86_64-pc-linux-gnu --disable-multilib

高版本GCC可加--disable-werror以免导致各种警告错误

sudo make sudo make install

2）然后导出linux头文件到工具链:

cd linux-2.6.33.3sudo make ARCH=x86_64 INSTALL_HDR_PATH=/usr/local/gcc443/x86_64-pc-linux-gnu headers_install

要用到perl.tcz

3. 构建GCC工具框架，不带任何库。

cd gcc-4.4.3 && sudo make b && cd bsudo ../configure --prefix=/usr/local/gcc443 --target=x86_64-pc-linux-gnu --enable-languages=c,c++ --disable-multilib

如果使用的3.x的make 3.8.2会出现configure错误：mixed rule

sudo make all-gcc sudo make install-gcc

4. 生成glibc的基础部分

第三步已经将工具生成了，现在最重要的基础库的基础部分，注意还不是整个glibc

预先export PATH=$PATH:/usr/local/gcc443/bin帮助接下来的configure找到新编译出的x86_64-pc-linux-gnu-gcc，虽然configure会自动找到，手动一下更保险

cd glibc-2.12.1 && sudo make b && cd bsudo ../configure --prefix=/usr/local/gcc443/x86_64-pc-linux-gnu --build=$MACHTYPE --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-headers=/usr/local/gcc443/x86_64-pc-linux-gnu/include --disable-multilib libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

$MACHTYPE在正常的linux32上会输出i686-pc-linux-gnu字样，在tinycolinux上输出为空，继续

如上语句在tinycolinux上一次通过，但在普通linux上configure似首很容易把glibc源码目录被破坏，即使是cd 到b中，比如你也许会碰到：cannot compute suffix of object files或者： invalid host type: $CXX unregconnize -c，并不网上说的解决办法能解决的，往往重新准备glibc源码目录重新按上面的configure来配置就好了，在普通linux上，glibc源码目录下的scripts/gen-sorted.awk 19行以后会出现需要将/[^/]+$ 改成 /[^/]+$的BUG，修正就好了。

然后就是make了：

a) sudo make install-bootstrap-headers=yes install-headers

在tinycolinux上一次通过，在普通linux上，你或许需要在make后额外加CFLAGS="-O2 -U_FORTIFY_SOURCE" cross-compiling=yes以分别应付下列可能出现的错误。

cross-compiling=yes : No rule to make target `elf/soinit.os' error CFLAGS=02 : glibc cant continues without opt error -U_FORTIFY_SOURCE : inlining failed in call to 'syslog' error

如果在不纯净的tinycolinux上执行a)，可能会出现需要tls support error

b) sudo make csu/subdir_lib

如果在不纯净的tinycolinux上执行b)，会继续出错

c) install csu/crt1.o csu/crti.o csu/crtn.o /usr/local/gcc443/x86_64-pc-linux-gnu/lib

d) x86_64-pc-linux-gnu-gcc -nostdlib -nostartfiles -shared -x c /dev/null -o /usr/local/gcc443/x86_64-pc-linux-gnu/lib/libc.so

e) touch /usr/local/gcc443/x86_64-pc-linux-gnu/include/gnu/stubs.h

如果在纯净的tinycolinux上，可以无误一直执行到e)，一般到这接下来二步都能完成。

5)生成GCC的LIBGCC

重新cd gcc-4.4.3/b sudo make all-target-libgcc sudo make install-target-libgcc

6)最后一步，生成完整的glibc和gcc中的stdc++lib

重新cd glibc-2.12.1/b sudo make sudo make install

重新cd gcc-4.4.3/b sudo make sudo make install

其实如上三部曲的编译还有很多联合构建的选项。但是本文不深究了。

测试编译64位程序并运行

先写一个CPP的helloworld,test.cpp

#include int main() {    printf("Hello World");    return 0;}

然后分别/usr/local/gcc443/bin/x86_64-pc-linux-gnu-g++ test.cpp -o a,/usr/local/gcc443/bin/x86_64-pc-linux-gnu-g++ -static test.cpp -o b,file a,file b，发现都是64位程序，我们发现b可以直接运行，而a显示not found，跟文章开头说的没有64位的GCC和binutils一样原因，那么现，我们讨求用新编译出的工具链让它运行的方法：

其实原因就是找不到共享库，error cant find share libs, ELF64CLASS，我们不能用32位的LDD分析它的依赖关系，但我们可以cd a所在的目录，x86_64-pc-linux-gnu-readelf -a ./a | grep "Shared"或x86_64-pc-linux-gnu-objdump -p ./a | grep NEEDED的方式查看，发现它引用了libc.so.6(->libc-2.12.1.so),libstdc++.so.6(->libstdc++.so.6.0.13),libgcc_s.so.1,libm.so.6(->libm-2.12.1.so)，当然了，这些库都要从新编译出的工具链的lib或lib64中找，放到a的目录，然后在a的目录下写个runa，加起执行权限，内容为：

D=$(dirname $0)$D/ld-linux-x86-64.so.2 --library-path $D:$D/lib:$D/usr/lib ./a $@(ld-linux-x86-64.so.2也是从工具链中找到的，它其实可以被执行，你也可以定制上面的--library-path)

执行./runa，输出跟静态b一样的结果。

这从理论上说明，只要系统支持默认的ld-linux-x86-64，它就支持运行一切由这个新工具链产生的程序。

现在，64位的kernel有了，生成64位程序的toolchain有了（它本身还是32位程序只是也能处理64位生成的事），但是整个ROOTFS还是基本上32上的，连运行它生成的64位程序的事都管不了，应该要重新编译busybox让它支持新的64位ld。

还有，可以以这个TOOLCHAIN为基础，不断bootstrap高版本的GCC，或者inplace覆盖，或变动BUILD，HOST进行，产生新的toolchains.

感谢各位的阅读，以上就是"如何在tinycolinux32上安装tinycolinux64 kernel和toolchain"的内容了，经过本文的学习后，相信大家对如何在tinycolinux32上安装tinycolinux64 kernel和toolchain这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！