Re: nss_ldap broken

On Thu, 1 Apr 2004, Oliver Eikemeier wrote:

> Daniel Eischen wrote:
> 
> > On Thu, 1 Apr 2004, Jacques A. Vidrine wrote:
> > 
> > [...]
> >>It seems to me we need one of a few things to happen to our threads
> >>implementation*s*:
> >>
> >>  (a) pthread.h provides all the magic needed to make pthread_*
> >>      symbols weak, i.e. transparently providing the functionality of
> >>      the `libgcc hack' which Dan says would avoid the problem.
> > 
> > 
> > I don't think that will work; it'll break applications/libraries
> > not expecting those functions to be NULL.
> > 
> > 
> >>  (b) ``somehow'' arrange for the unloading of a thread library to
> >>      fixup the pthread stubs `back to normal'.  er, that sounds like
> >>      a load of work and dangerous to boot.
> >>
> >>  (c) teach rtld to treat thread libraries specially: ignore them during
> >>      dlopen even if they are specified in DT_NEEDED.  perhaps we could
> >>      add some info to the ELF headers of our thread libraries that rtld
> >>      could use to implement this.  hacky.
> > 
> > 
> > I think the best way is to avoid having shared libraries needlessly linked to 
> > a threads library.
> 
> I don't think this is really an option, since you expect too much testing from

Isn't it being tested with -pthread under -stable enough
to indicate that it isn't going to break anything?

> ports maintainers here. It may be difficult to tweak the ports Makefiles if
> the port has shared libraries and applications, and most maintainers won't
> notice this anyway. For example Berkeley DB is linked against libpthread, so
> I had to be careful what OpenLDAP parts I link to Berkeley DB. You can build
> nice and complex chains here.

-- 
Dan Eischen