bin/90367: libmap.conf needs exclusivity support

Nick Johnson freebsd at
Tue Dec 13 15:20:34 PST 2005

>Number:         90367
>Category:       bin
>Synopsis:       libmap.conf needs exclusivity support
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 13 23:20:02 GMT 2005
>Originator:     Nick Johnson
>Release:        FreeBSD 6.0-STABLE i386
System: FreeBSD 6.0-STABLE FreeBSD 6.0-STABLE #2: Tue Dec 6 08:53:05 PST 2005 root at i386


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***   # 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.



More information about the freebsd-bugs mailing list