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
State Changed From-To: open->suspended Mark as suspended awaiting someone to generate a patch for this.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"