nss_ldap broken

Oliver Eikemeier eikemeier at fillmore-labs.com
Thu Apr 1 06:04:58 PST 2004

Daniel Eischen wrote:

> On Thu, 1 Apr 2004, Oliver Eikemeier wrote:
>>- it should be documented somewhere (bsd.port.mk gives you only PTHREAD_LIBS)

As far as I understand the problem, every application that doesn't link to
pthreads, but uses a library that does crashes on -CURRENT. Am I right there?

>>- 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.

See my answer in the last paragraph.

>>- 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 guess the latter approach will be preferrable, especially since the
former does seem to trigger the problem we have...

>>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
> breaks.

We can change the default for all ports, and it is (more or less) easy to
override the flags in one port, if it uses the wrong ones. I think it is not
really feasable to change ports so that libraries and applications are linked
with different flags.

Currently I returned to accepting the default OpenLDAPs configure gives me, which
is -pthread. This is *not* what bsd.port.mk has (-lpthread). What would be the
consequences of changing the default back to -pthread?


More information about the freebsd-current mailing list