Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 01 Apr 2004 11:49:22 +0200
From:      Oliver Eikemeier <eikemeier@fillmore-labs.com>
To:        Sean McNeil <sean@mcneil.com>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: nss_ldap broken
Message-ID:  <406BE5A2.8020106@fillmore-labs.com>
In-Reply-To: <1080773331.1956.36.camel@server.mcneil.com>
References:  <Pine.GSO.4.10.10403311642150.28223-100000@pcnet5.pcnet.com> <1080773331.1956.36.camel@server.mcneil.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Sean McNeil wrote:
> On Wed, 2004-03-31 at 13:48, Daniel Eischen wrote:
> 
>>On Mon, 29 Mar 2004, Daniel Eischen wrote:
>>
>>
>>>On Mon, 29 Mar 2004, Jacques A. Vidrine wrote:
>>>
>>>
>>>>Sean, could you report how this patch works for you?  Hmm, actually, it
>>>>looks almost identical to what you posted :-)  Is there a reason that
>>>>you stored the value of `__isthreaded' in a local variable?  Did that
>>>>make a difference for your case?
>>>
>>>I'm unsure how nss_ldap was built to depend on libpthread (or
>>>any threads library).  I built it from ports and 'ldd' didn't
>>>report any dependency on a threads library.
>>
>>I rebuilt it and now it does depend on libpthread.  I
>>think it is because I had openldap-client-2.1.26 which
>>didn't have a dependency on libpthread, but upgrading
>>to openldap-client-2.1.28 brought in the dependency.
>>
>>Too bad these shared libraries can't be made to use
>>the libgcc trick, so they can still be thread-safe
>>but not depend on a threads library.  That would
>>also make it easier to use different thread libraries
>>for different applications relying on common shared
>>libraries.
> 
> 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?

-Oliver



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?406BE5A2.8020106>