How to point to new gcc libs (instead of default gcc)
Wed Feb 3 05:42:00 GMT 2010
On 02/03/2010 05:48 AM, Zvi Vered wrote:
> I used crostool-ng 1.5.2 to build a toolchain for x86-32 (linux
> 188.8.131.52, gcc 4.3.2, glibc 2.9)
> I used the -L switch to point to the path of the libs created with the
> toolchain (/opt/toolchain/i686-nptl-linux-gnu/sys-root/usr/lib)
With a properly configured and installed cross-toolchain, gcc
automatically picks up the linktime libraries (-L) from internal library
> But when I did: ldd my_app.out I got:
> ldd my_app.out
> linux-gate.so.1 => (0x00f61000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x0074d000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x03653000)
> librt.so.1 => /lib/librt.so.1 (0x0077c000)
> libc.so.6 => /lib/libc.so.6 (0x005d6000)
> /lib/ld-linux.so.2 (0x005b3000)
> libm.so.6 => /lib/libm.so.6 (0x0071e000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0059e000)
> It seems that the out file is linked dynamically against the list is
> /usr/lib and not "my" libs.
Consider you are cross-compiling.
ldd is a native tool, reporting an application's dynamic runtime
libraries inside of your current runtime-enviroment.
i.e. the output it produces on cross-built applications is bogus.
You need to run your target's ldd on the target you are cross-building
for, to see correct output.
> Can I fix it with a gcc switch ?
No, you can't.
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc