> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so > (without a specific version number). ld.so is picking the latest and > loading it, but libc.so.98.0 was already loaded, so we hit msyscall > error.
Time to explain the msyscall thing a bit. msyscall(2) will go away after release, since pinsyscalls(2) has replaced it. msyscall(2) was the first mechanism for "range of memory where system calls occur from", pinsyscalls(2) is the new mechanism with "precise entry points for system calls". The failure to msyscall(2) prints a warning message in ld.so. But the failure of pinsyscalls(2) in ld.so does not print a warning message. However the pinsyscalls(2) failure is visible in the ktrace. Both of them fail. The reality is if a system call is called from that 2nd libc.so library mapping, the process will exit hard with SIGABRT. It isn't the msyscall message that matters here, but that you simply can't have another region containing the ability to call system calls. ld.so was modified to coerce additional "libc.so" mapping requests into reusing the first libc.so choice made by ld.so. The ld.so/loader.c logic has not chosen to do that in this case, and I can't see why that didn't happen. There's two bugs, really. 1. the application chose to load another library version, because it is compiled or discovered somehow. We cannot find and fix all those cases because programs do really weird things to get those library names. 2. ld.so must do the job of coercing all "libc.so*" requests to the original libc.so choice, and the ld.so diff isn't sufficient for this case. We can't fix 1, so #2 is what kettenis has been trying to do.
