Re: [root%mail.asta.uni-rostock.de@localhost: pkgsrc DragonFly 1.4.0/i386 bulk build results]

[joerg%britannica.bec.de@localhost]

On Wed, Feb 01, 2006 at 08:47:01AM -0800, Jeremy C. Reed wrote:
> > > +# the following is a work-around because $PREFIX/qt3/lib/libqt-mt.so
> > > +# didn't link with pthread
> > > +# need to fix libqt3 package?
> > > +CONFIGURE_ENV+=                qt_cv_libname=-lqt-mt
> > 
> > This is not a problem of the libqt3 package, but of configure script.
> > Linking against a threaded library (not a thread-aware library) needs
> > PTHREAD_* flags, it should be done for consistence also on other
> > platforms BTW.
> 
> Okay. It is just not noticed, because on Linux and NetBSD, the libqt-mt 
> shared library depends on libpthread.so.

libtool would pull the -pthread in automatically, but not -lc_r. Let me
add some more background. One year ago or so, we split the original
libc_r in DragonFly in the libc and the pthread part. FreeBSD 4's libc_r
replaces libc, e.g. contains a full copy of it.

Back at that time, we also added stubs for almost all pthread functions,
so that thread-aware libraries can be linked with just libc, but don't
need to link libc_r. Thread-aware means it uses e.g. mutexes, but
doesn't need threads. We had the discussion how to prevent abuse and
that resulted in pthread_create not being included, since that function
a very strong indicator that the library is not only thread-aware, but
needs real threading.

This is the reason that -lc_r is not included as dependency lib, since
threaded libraries *must* link against libc_r directly, otherwise all
kind of nasty issues can pop up, e.g. when it is pulled in later via
dlopen. The linker can't detect that, but libc's internal state can be
easily corrupted that way. Just think about stdio's locking.

Joerg