几年前在接触BCM7403时，曾经遇到一个toolchain上的问题：
当时本人喜欢将Toolchain放到自己指定的位置，如：
/home/本人/work/current/BCM/BCM7403/ToolChain/crosstools_sf-linux-2.6.12.0_gcc-3.4.6-21_uclibc-0.9.28-20050817-20070607
一直未遇到什么问题，但用不规范方式混嵌入式的，迟早要还的。
在如此安装BCM7403本人编译任何程序时，都会遇到如下错误：
/home/本人/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/本人/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/本人/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
本人同学相当的疑惑，这些库都应该是toolchain维护的阿，为啥会找不到呢？当时为了解决问题，于是按照说明中所说，在LFLAGS中添加了：-Wl,-rpath-link -Wl,/home/本人/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
问题才得以解决。见()
并猜测是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/本人/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 or directory
collect2: ld returned 1 exit status
Trident工程师给出的方案是：ld时添加
--sysroot=
/home/本人/work1/current/Trident/Trident_Develop/SRC/open_source_archive/linux/toolchains/gnu_cortex-a9_tools/
本人看到后觉得好像与之前遇到的问题类似，都是找不到基础库(crt1.o好像是用来在main之前构建环境并加载的)。
但游戏开发中用到非常多的OpenSource,自身的工程也非常多，如果一个个添加，好像很BT。 所以本人准备先解决之。
于是再次使用：
#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放置到如上目录。呵呵，问题解决了。
本人估计问题与之前的相同。