nss_ldap broken
Daniel Eischen
eischen at vigrid.com
Thu Apr 1 08:41:06 PST 2004
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
More information about the freebsd-current
mailing list