nss_ldap broken

[Jacques A. Vidrine]

On Thu, Apr 01, 2004 at 11:49:22AM +0200, Oliver Eikemeier wrote:
> Sean McNeil wrote:
> >I'm unclear as to why any library that is thread-safe would need to be
> >linked with libpthread.so. Since libc already has the hooks in there, I
> >don't see why you need to link with it unless you are actually
> >using/relying on threads.  IMHO, we should just not link libpthread.so
> >into these shared libraries.
> 
> I do understand some of the technical diffuculties here, but:
> 
> - it should be documented somewhere (bsd.port.mk gives you only 
> PTHREAD_LIBS)
> 
> - it requires some major surgery to ports makefiles to make sure that
>  libraries and application in a port are linked differently
> 
> - there should be some easy tests, i.e. is it always an error if ldd *.so
>  contains libpthread?
> 
> I committed a workaround for the OpenLDAP client port, but it seems that we
> have may this problem in other parts of the system too, so a general
> guideline (perhaps with a note in /usr/ports/CHANGES) would be appreciated.
> Or do I overestimate the extend of this issue here?

I don't know if you overestimate it or not for practical purposes, i.e.
I'm not sure how many applications are actually affected.  However, it
makes me quite nervous.  There are many uses of `plug-in' APIs that
involve dlopen/dlclose of dynamic objects.  So, I also think we should
codify how these cases should be handled.

I don't care for `the libgcc' hack... using #pragma seems inherently
non-portable.  Applications should not need to use anything other than
`#include <pthread.h>' and invoke pthread_* APIs.

Linking is inherently non-portable already :-) so perhaps requiring ``do
not link threading libraries with objects that do not contain `main'''
isn't such a burden.

Cheers,
-- 
Jacques Vidrine / nectar at celabo.org / jvidrine at verio.net / nectar at freebsd.org