Toolchain安装位置考
Sam几年前在接触BCM7403时，曾经遇到一个toolchain上的问题：
当时Sam喜欢将Toolchain放到自己指定的位置，如：
/home/sam/work/current/BCM/BCM7403/ToolChain/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607
一直未遇到什么问题，但用不规范方式混嵌入式的，迟早要还的。
在如此安装BCM7403Sam编译任何程序时，都会遇到如下错误：
/home/sam/work/current/BCM/BCM7403/ToolChain/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/bin/../lib/gcc/mipsel-linux-uclibc/3.4.6/../../../../mipsel-linux-uclibc/bin/ld:warning: ld-uClibc.so.0, needed by/home/sam/work/current/BCM/BCM7403/ToolChain/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/bin/../lib/gcc/mipsel-linux-uclibc/3.4.6/../../../../mipsel-linux-uclibc/lib/libc.so,not found (try using -rpath or-rpath-link)
/home/sam/work/current/BCM/BCM7403/ToolChain/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/bin/../lib/gcc/mipsel-linux-uclibc/3.4.6/../../../../mipsel-linux-uclibc/lib/libc.so:undefined reference to `__libc_stack_end'
collect2: ld returned 1 exit status
Sam同学相当的疑惑，这些库都应该是toolchain维护的阿，为啥会找不到呢？当时为了解决问题，于是按照说明中所说，在LFLAGS中添加了：-Wl,-rpath-link-Wl,/home/sam/work/current/BCM/BCM7403/ToolChain/crosstools_sf-linux-\
2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/mipsel-linux/lib
问题才得以解决。见blog(http://blog.sina.com.cn/s/blog_602f87700100fbm3.html)
并猜测是toolchain作的不太好，库的位置被固定在哪里了。
但郁闷之情未解阿，于是看看toolchain信息。
#mipsel-linux-gcc -v
../gcc-3.4.6/configure--prefix=/opt/toolchains/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/--target=mipsel-linux-uclibc --build=mipsel-linux--host=mipsel-linux --enable-target-optspace --disable-nls--with-gnu-ld --enable-shared --enable-languages=c,c++--enable-threads--infodir=/opt/toolchains/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/info--mandir=/opt/toolchains/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/man--disable-__cxa_atexit --disable-checking --with-arch=mips32--with-float=soft
Thread model: posix
gcc version 3.4.6
看到--prefix=/opt/toolchains/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607/这里时，突然想到，会不会是要将toolchain放到此指定目录呢？于是测试之，发现问题被解决了。
总结如下：
某些toolchain会指定希望自己存放的位置，这样的话才可以顺利找到自己的库。
前文说了这么多，终于说到现在了。最近公司需要在Trident的PNX84xx上编译游戏。之前负责的同事遇到一个问题如下：
使用Trident的SDK安装toolchain后，编译编译时会出如下问题：
arm-linux-gcc test.c -o test
/home/sam/work1/current/Trident/Trident_Develop/SRC/open_source_archive/linux/toolchains/gnu_cortex-a9_tools/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/bin/ld:crt1.o: No such file: No such file ordirectory
collect2: ld returned 1 exit status
Trident工程师给出的方案是：ld时添加
--sysroot=
/home/sam/work1/current/Trident/Trident_Develop/SRC/open_source_archive/linux/toolchains/gnu_cortex-a9_tools/
Sam看到后觉得好像与之前遇到的问题类似，都是找不到基础库(crt1.o好像是用来在main之前构建环境并加载的)。
但游戏开发中用到非常多的OpenSource,自身的工程也非常多，如果一个个添加，好像很BT。 所以Sam准备先解决之。
于是再次使用：
#arm-linux-gcc -v
Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with:/build/dev/nitingarg/buildroot/toolchain_build_arm/gcc-4.4.0/configure--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu--target=arm-linux-uclibcgnueabi --enable-languages=c,c++--with-sysroot=/build/dev/nitingarg/buildroot/build_arm/staging_dir--with-build-time-tools=/build/dev/nitingarg/buildroot/build_arm/staging_dir/usr/arm-linux-uclibcgnueabi/bin--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld--disable-libssp --disable-tls --enable-shared--with-gmp=/build/dev/nitingarg/buildroot/toolchain_build_arm/gmp--with-mpfr=/build/dev/nitingarg/buildroot/toolchain_build_arm/mpfr--disable-nls --enable-threads --enable-multilib--disable-decimal-float --with-abi=aapcs-linux --with-arch=armv7-a--with-tune=cortex-a9
Thread model: posix
gcc version 4.4.0 (GCC)
这次看到的是--with-sysroot=/build/dev/nitingarg/buildroot/build_arm/staging_dir
于是将Trident的toolchain放置到如上目录。呵呵，问题解决了。
Sam估计问题与之前的相同。
所以说，在嵌入式开发中，最好将toolchain安装到某特定目录中。