Dear Andrew,<div>I perform "gcc -v", and this is the result:</div><div><div>Using built-in specs.</div><div>Target: arm-eabi</div><div>Configured with: /home/jingyu/projects/gcc/android-toolchainsrc/build/../gcc/gcc-4.4.3/configure --prefix=/usr/local --target=arm-eabi --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --with-gmp=/home/jingyu/projects/gcc/toolchain_build/gingerbreadobj/temp-install --with-mpfr=/home/jingyu/projects/gcc/toolchain_build/gingerbreadobj/temp-install --disable-libssp --enable-threads --disable-nls --disable-libmudflap --disable-libgomp --disable-libstdc__-v3 --disable-sjlj-exceptions --disable-shared --disable-tls --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace --with-abi=aapcs --with-gcc-version=4.4.3 --with-binutils-version=2.19 --with-gmp-version=4.2.4 --with-mpfr-version=2.4.1 --with-gdb-version=7.1.x --with-arch=armv5te --with-multilib-list=mandroid --with-sysroot=/usr/local/google/home/android/cupcake_rel_root --enable-gold=both/gold --program-transform-name='s&^&arm-eabi-&'</div>
<div>Thread model: single</div><div>gcc version 4.4.3 (GCC)</div><div><br></div><div>It seems to look for libs via absolute path. Right?</div><div>Oh, did you mean set this path [LDFLAGS="-Wl,-rpath,$PREFIX/lib"] as relative path ?</div>
<div>If so...but i don't know how to set, could you pls kindly help me ?</div><div><br></div><div><br><br><div class="gmail_quote">On Thu, May 24, 2012 at 9:56 PM, Andrew Bradford <span dir="ltr"><<a href="mailto:andrew@bradfordembedded.com" target="_blank">andrew@bradfordembedded.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 24 May 2012 07:52:51 -0500<br>
DJ Lucas <<a href="mailto:dj@linuxfromscratch.org">dj@linuxfromscratch.org</a>> wrote:<br>
<br>
> On 05/24/2012 06:36 AM, Andrew Bradford wrote:<br>
> > On Thu, 24 May 2012 13:03:12 +0800lee sudo<<a href="mailto:desoxydate@gmail.com">desoxydate@gmail.com</a>>  wrote:<br>
> ><br>
> >> But I find some cross toolchains (e.g. cross toolchain in android source<br>
> >> code) could work well after change its path(anywhere).<br>
><br>
> git<br>
> clone|<a href="https://android.googlesource.com/platform/manifest||for" target="_blank">https://android.googlesource.com/platform/manifest||for</a> the whole<br>
> schebang, or dig a little deeper for only the toolchain, I believe<br>
> platform/||prebuilt/linux-x86/toolchain/arm-eabi-${GCC_VERSION}||.|<br>
> ||<br>
<br>
Thanks! I question Google's need for putting compiled gcc versions in a<br>
git tree, but that's a separate debate :)<br>
<br>
It looks like Google's Android gcc, so long as you move the entire<br>
'prebuilt/linux-x86/toolchain/$ARCH' directory structure around as one<br>
unit, is using relative paths for their GCC.  Their gcc, for example,<br>
looks for libs in '../lib/gcc/$ARCH/$GCC_VERSION', relative to the gcc<br>
binary.<br>
<br>
If you build your GCC like Google does, you should get the same<br>
effect.  CLFS doesn't have you do it the Google way, CLFS is more like<br>
how Emdebian's cross compilers are built, with explicit paths to find<br>
libs.  I don't know how to tell you how to do it the Google way, but<br>
the GCC manuals should.<br>
<br>
-Andrew<br>
_______________________________________________<br>
Clfs-dev mailing list<br>
<a href="mailto:Clfs-dev@lists.cross-lfs.org">Clfs-dev@lists.cross-lfs.org</a><br>
<a href="http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org" target="_blank">http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Thanks & BR,</div><div>sudolee<br></div><br>
</div></div>