Toolchain安装位置考

几年前在接触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放置到如上目录。呵呵,问题解决了。

本人估计问题与之前的相同。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wwfyxx.html