On 5.2.2010 11:40, fanqifei wrote: > 在 2010年2月4日 下午5:26，刘卓 <lzhskywalker@xxxxxxxxx> 写道： > >> I've tried this instruction. But it seems I have encountered a very >> popular problem as shown below: >> >> checking whether the >> /root/mips-octeon-linux-gnu-toolchain/build-gcc-bootstrap/./gcc/xgcc >> -B/root/mips-octeon-linux-gnu-toolchain/build-gcc-bootstrap/./gcc/ >> -B/opt/octeon/mips-octeon-linux-gnu/bin/ >> -B/opt/octeon/mips-octeon-linux-gnu/lib/ -isystem >> /opt/octeon/mips-octeon-linux-gnu/include -isystem >> /opt/octeon/mips-octeon-linux-gnu/sys-include linker >> (/root/mips-octeon-linux-gnu-toolchain/build-gcc-bootstrap/./gcc/collect-ld) >> supports shared libraries... yes >> checking dynamic linker characteristics... configure: error: Link >> tests are not allowed after GCC_NO_EXECUTABLES. >> make[1]: *** [configure-target-libssp] Error 1 >> >> I've searched over the Internet, but I can't find an appropriate >> solution, since I'm building an octeon platform oriented cross >> compiler. And the solutions and discussions about this problem on the >> internet is quite a chaos... I didn't figure out a clue. >> The problems will arise from the attitude: "A cross GCC isn't or it SHOULD NOT be just like a native GCC!". So people will use all possible ways to get the build prerequisites : - the target binutils are installed and working - the target C library is installed and working being worked around, especially the second prerequisite :( There is that new stupidity which states that people SHOULD ALWAYS build the target C library, although already existing and thoroughly tested, during a cross GCC build... But if one hasn't this attitude, then the cross GCC build is much easier and quicker than an equivalent native GCC build with its usual 3-stage bootstrap process! A native GCC usually expects it binutils being in '/usr/bin' and its target C library being in '/usr/include' and '/usr/lib'. Traditionally a cross GCC has expected the target binutils and C library being in the chosen '$prefix/$target' (bin, include, lib) but nowadays the usual place for the target C library is in a $sysroot, the install scheme for it there is identical with a native GCC. The '--with-sysroot=$sysroot' will be used in configure to point to this place so 'ld' and GCC will find it there. The binutils (executables made for the $host) will stay in their traditional place but the purely $target dependent C library will be put to that $sysroot for the "alien host". If one uses the cross GCC, the with-it produced alien stuff could be also installed into the $sysroot ... So the best advice is: "Don't be stupid and believe every bullshit in the net, but use your own brains!" If we believe everything we see then we soon will believe the rain always coming as frogs in USA (the movie "Magnolia"). What is so hard to believe in the "a cross GCC build is just like a native GCC build but much easier!" fact?
