On Sat, Apr 2, 2016 at 2:26 PM, Mark Kettenis <[email protected]> wrote: >> Date: Fri, 1 Apr 2016 23:18:19 -0700 >> From: Philip Guenther <[email protected]> ... >> This version also implements the pattern I intend to apply to libc at some >> point, where symbols in the shared library are always strong (as the >> shared library search order handles conflicts) and only the static library >> have symbols that are weakened. > > Trying to understand the consequences of this... > > This "breaks" the case where a shared library further down the chain > provides a strong definition of a symbol and expects this to override > the definition in libpthread. I suppose that if this is a deliberate > choice of the application writer, they should just make sure this > library gets linked before libpthread. But what if this is a choice > made by a shared library writer? I suppose our position is that this > isn't supported?
Correct. Note that this is not a change for libpthread: everything in libpthread has always been strong, so it's already the case that if you want to override something in libpthread, you need to link it earlier. As for libc, well, libc should always be last in linking anyway. For most libc.so symbols, making them strong again** will be a return to how things were in 5.8 and earlier, before l2k15 when we weakened many symbols. Philip Guenther ** "If given a commit bit, I promise to make libc strong again!" -- Donald Trump, developer <runs away from the tomatoes>
