Re: nss_ldap broken

Jacques A. Vidrine wrote:


>>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 don't know if you overestimate it or not for practical purposes, i.e.
> I'm not sure how many applications are actually affected.  However, it
> makes me quite nervous.  There are many uses of `plug-in' APIs that
> involve dlopen/dlclose of dynamic objects.  So, I also think we should
> codify how these cases should be handled.
> 
> I don't care for `the libgcc' hack... using #pragma seems inherently
> non-portable.  Applications should not need to use anything other than
> `#include <pthread.h>' and invoke pthread_* APIs.
> 
> Linking is inherently non-portable already :-) so perhaps requiring ``do
> not link threading libraries with objects that do not contain `main'''
> isn't such a burden.

As mentioned before: it isn't that easy to patch a port so that applications
and shared libraries are linked to different libraries. Of course it could
be done, but you put a major burden on port maintainers here, and you will
introduce errors in the process. Berkeley DB is linked against libpthread for
example, so my workaround in OpenLDAP was to be careful what I link with
Berkely DB. It looks like this would open a whole can of worms...

-Oliver