Re: nss_ldap broken

On Thu, 1 Apr 2004, Oliver Eikemeier wrote:

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

No, I don't think that is the case, but that is really a separate
issue.


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

Right, especially for ports that have both libraries and applications.

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

It looks like -pthread in -stable has the same behavior (avoids
linking to libc_r when liking shared), so there will probably
no problems.

This should probably go to -ports now...

-- 
Dan Eischen