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"

    Relevant Pages

    • Re: Assertion failuers
      ... it occasionally core dumps on solaris 2.9. ... > i was wondering the use of above flags ... --disable-shared will turn off the building of shared libraries ... it is best if you build your libraries and applications ...
      (comp.protocols.kerberos)
    • Re: 32 bit ports on an AMD64 system
      ... You've given some of your reasons for using amd64 -- but are your ... you use a different LOCALBASE for 32-bit ports, ... between 32-bit and 64-bit versions of the same libraries depending ... kernel modules is a bit more important to me. ...
      (freebsd-questions)
    • Re: rtld or lang/gcc cannot find libgcc_s.so.1
      ... ports, so others are likely to hit this issue. ... of tree GCC, maybe we need to revisit the idea. ... information from all the libraries that might satisfy the search before ...
      (freebsd-current)
    • Re: the more build knobs bikeshed
      ... minimum set of libraries as well. ... And it doesn't work with cross building because of its use of LDD. ... Tinybsd uses the binaries on your system rather than building them. ... cooperative ports would work... ...
      (freebsd-arch)
    • Re: CURRENT && /usr/ports
      ... 1200 ports I'm used to use. ... The policy that we are trying to follow with regard to the userland ABI ... libraries includes libc, libpthread, libm and libstdc++. ... libraries that also implement symbol versioning, ...
      (freebsd-current)