Re: dlopen() and libpthread

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Oct 20, 2012 at 02:12:16AM +0200, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> 
> > > And my question is: why should libpthread be forbidden for dlopen(3)?
> > Because the dynamic loader cannot travel backwards in time and cause libc
> > to have started up, in the past, with threading enabled.
> 
> It would be nice if dlopen() could still succeed while not loading
> libraries taggged NOOPEN. If it is not really needed, that works. If the
> library was required, we get a hard failure when a missing symbol is
> called.

You do not get a hard error. That was the really, really big issue we
have seen countless of times. For example, stdio locking will simple not
work, since the libc stubs for mutexes are effectively noops. The
symbols have been resolved already at the time libpthread is added, so
there is no way to fix it up. It might "work" in some cases, because
there are no race conditions or the races are not visible. But that is
just a question of good/bad luck, not a design decision. The only
instances where it is really safe is if and only if libpthread was not
really needed in first place.

Joerg