nss_ldap broken

Daniel Eischen eischen at vigrid.com
Thu Apr 1 05:20:39 PST 2004

On Thu, 1 Apr 2004, Oliver Eikemeier wrote:

> Sean McNeil wrote:
> > On Wed, 2004-03-31 at 13:48, Daniel Eischen wrote:
> > 
> >>On Mon, 29 Mar 2004, Daniel Eischen wrote:
> >>
> >>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

I think if you use -pthread instead of -lpthread, it will not
link to the threads library when building a shared library.
Unfortunately, Linux and others seem to have changed their
-pthread behavior so that it no longer avoids linking to
the threads library when building shared.  So -pthread may
work for us now, but we may want [be forced] to change.

> - there should be some easy tests, i.e. is it always an error if ldd *.so
>   contains libpthread?

I think it is dependent on the library.  If the library truly is
creating threads behind the scene (suppose there were a libaio)
then it needs the threads library.

On the other hand, for applications that want to use libaio, you
could force them to link to a threads library instead of having
it automatically brought in by libaio.

> 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 would suspect that most libraries don't create threads on
their own, but it would require maintainers to know a little
more about their ports.  I'm not sure there's one easy solution,
but I suppose you could try rebuilding ports with
PTHREAD_LIBS=-pthread to see if that helps and what it

Dan Eischen

More information about the freebsd-current mailing list