Re: nss_ldap broken

From: Daniel Eischen (eischen_at_vigrid.com)
Date: 04/01/04

  • Next message: Max Laier: "Re: Comments: pflog rc.d-script"
    Date: Thu, 1 Apr 2004 10:04:12 -0500 (EST)
    To: Oliver Eikemeier <eikemeier@fillmore-labs.com>
    
    

    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
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    

  • Next message: Max Laier: "Re: Comments: pflog rc.d-script"