On 03/24/2016 12:31 AM, john hood wrote: > I haven't been able to chase these glibc details down. Do you have > pointers to specifics for this? My assessment was based just on reading the referenced glibc-help thread, and the commit it referenced -- https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=beff1d132c16aedd87a3f1bc7b572c8e69819015
The commit contains this comment ahead of the "trampoline" generation: /* libpthread once had its own fork, though there was no apparent reason for it. There is no use in having a separate symbol in libpthread, but the historical ABI requires it. For static linking, there is no need to provide anything here--the libc version will be linked in. For shared library ABI compatibility, there must be __fork and fork symbols in libpthread.so; so we define them using IFUNC to redirect to the libc function. */ There is also some further discussion on the glibc thread since it was first referenced here. To summarize some key items from that: "this is a bug. Could you report it in Bugzilla here, please?" "The commit you identified, beff1d132c16aedd87a3f1bc7b572c8e69819015, assumes that __libc_fork has been relocated before the IFUNC resolver for the libpthread fork definition runs, which is not always true." https://sourceware.org/bugzilla/show_bug.cgi?id=19861 So it looks like, contrary to my assessment (I said I wasn't an expert :), this *is* a glibc bug. But the mosh workaround is probably still necessary in the short term.
