Hello, i tried -static-libgcc, but it had no effect. the dependencies are already there. the statically linked glibc libraries into my shared library causes the dependence on libc.so.6.
uclibc are often built against the kernel headers of the target system during crosscompilation. i am going to test if this is the problem. Thanks, Matthias > On Wednesday 21 April 2010 08:23:40 Matthias Hofmann wrote: >> Hello, >> >> typing ldd to the shared library has the following output: >> >> linux-gate.so.1 => (0xb7fad000) >> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d5f000) >> libm.so.0 => /usr/lib/libm.so.0 (0xb7d52000) >> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d48000) >> libc.so.0 => /usr/lib/libc.so.0 (0xb7cfb000) >> libc.so.6 => /lib/libc.so.6 (0xb7bce000) >> ld-uClibc.so.0 => /usr/lib/ld-uClibc.so.0 (0xb7bc7000) >> /lib/ld-linux.so.2 (0xb7fae000) >> >> seems to me that he is using both versions of libc, the glibc and >> uclibc. >> maybe he uses the wrong libc version to call sem_open? > > Libraries can link against other libraries. You grabbed one of the > versions > of a library (probably your libgcc_s.so.1) which leaked a reference to > libc.so.6, because that's what it had been linked against. > > Try adding the "--static-libgcc" flag to your build. > > Rob > -- > Latency is more important than throughput. It's that simple. - Linus > Torvalds > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
