Date: Thu, 1 Apr 2004 10:04:12 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: Sean McNeil <sean@mcneil.com> Subject: Re: nss_ldap broken Message-ID: <Pine.GSO.4.10.10404010949150.25682-100000@pcnet5.pcnet.com> In-Reply-To: <406C217A.8080102@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10404010949150.25682-100000>