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?
-Oliver
More information about the freebsd-current
mailing list