On Thu, 23 Jun 2005, Dan Nelson wrote:
In the last episode (Jun 23), Kevin S. Brackett said:libc.so.4 => /usr/lib/libc.so.4 (0x28755000) libc_r.so.4 => /usr/lib/libc_r.so.4 (0x287ee000)any ideas why it's doing this, and what the fix is?Looks fine to me: libc.so.5 => /lib/libc.so.5 (0x2875c000) libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28836000) Is this a machine recently upgraded from 4.*? Does "ldd -a ices" indicate that those libs are being pulled in as dependencies of another library? If so, rebuild that port, then rebuild ices. Here is a script to find all the binaries linked to superceded port libs and libs directly linked to threads libs: #! /bin/sh ( find -s /usr/local/lib /usr/X11R6/lib -name "lib*.so" find -s /usr/local/bin /usr/X11R6/bin/ ) | xargs ldd -a 2>/dev/null | awk ' /^[^\t]/ { cmd=$1 } /^\t.*\/compat\// { printf "%s\t%s\n",cmd,$3 } /^\t(libc_r|libpthread|libthr).so/ { printf "%s\t%s\n",cmd,$3 } '
Well, the problem is when libc and libc_r are linked together, I recompiled without -lc and it's now fine, but not really what i'd consider a great fix...
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
