Bug 90367

It is a fairly common problem that a program that uses dynamic linking
can end up linking multiple different implementations of the same library.
This can happen with Java programs that use JNI where the JNI shared
object file is linked with a different threading library than the Java
executable.

One way to deal with this might be to add exclusivity groups to libmap.conf.
For example, a directive might look like this:

Exclusive	libc_r.so* libpthread.so* libthr.so*  # globs might be nice too!

Then if the linker encounters a request for a shared object in an Exclusive
group, and something from that group has already been linked, no additional
linking will be performed.

In the case of posix threads, this should work well, because it's a
well-known API and private / undocumented functions shouldn't be used
anyway... (ie, if it works to change the mapping in libmap.conf, this
should work too).

The tricky bit would be knowing which shared objects had already been
linked to a running program, and doing all of this in a way that doesn't
hinder performance considerably.

Fix: 

n/a
How-To-Repeat: n/a