Re: cvs commit: src/gnu/usr.bin/cc34/cc_prep/config dragonfly-spec.h src/gnu/usr.bin/cc41/cc_prep/config dragonfly-spec.h

[Hasso Tepper <hasso@xxxxxxxxx>]

Simon Schubert wrote:
>   Now threaded programs do not get linked to libc_r anymore, but to the
>   proxy lib libpthread.  As soon as all programs and libraries are relinked
>   to use libpthread exclusively (and not libc_r.so anymore), threading libs
>   can be switched by changing the /usr/lib/libpthread.so.0 symlink.
>   
>   Use the following command to find all packages still linking to libc_r:
>   
>   find /usr/pkg/bin /usr/pkg/sbin /usr/pkg/lib /usr/pkg/libexec -type f \
>     -exec sh -c '\
>       objdump -p $0 2>/dev/null | grep -q "NEEDED.*libc_r\.so" || exit 0; \
>       pkg_info -F -e $0' {} \; | sort | uniq

Warning, you might still encounter problems after that. I just fought
with the problem "why the heck qt4 still tries to link against
libc_r.so?". I recompiled every package with files linked against
libc_r.so and the command above didn't return anything.

The problem was that qt4 uses pkg-config (obviously) to determine
flags to link against libgthread. Although libthread wasn't linked
against libc_r, gthread-2.0.pc contained:

$ cat /usr/pkg/lib/pkgconfig/gthread-2.0.pc | grep Libs
Libs: -Wl,-R${libdir} -L${libdir} -lgthread-2.0  -pthread -lc_r

Recompiling devel/glib2 solved the problem.


-- 
Hasso Tepper