Hi Florian, Thanks for your answers. On 04/19/2017 05:48 PM, Florian Weimer wrote: > On 04/19/2017 05:07 PM, Michael Kerrisk (man-pages) wrote: >> Am I right about my rough guess for the rationale for point 6, >> or is there something else I should know/write about? > > We currently have a bug where the symbol resolution depends on the order > of alternatives along a hash bucket list: > > <https://sourceware.org/bugzilla/show_bug.cgi?id=12977#c2> Okay. > Another open problem is what happens when a versioned symbol moves from > one DSO to another. This is not a problem for unversioned symbols, but > we currently have a soname check for versioned symbols. This is rather > odd because this check isn't used to accelerate lookups. It does not > prevent symbol interposition from other DSOs, it merely introduces > spurious failures. I have a vague recollection that this problem has been around for a very long time, right? >> 7. The way to remove a versioned symbol from a new release >> of a shared library is to not define a default version >> (NAME@@VERSION) for that symbol. (Right?) >> >> In other words, if we wanted to create a VER_4 of lib_ver.so >> that removed the symbol 'abc', we simply don't create use >> the usual asm(".symver") magic to create abc@VER_4. > > You still need to use .symver, but with a @ version instead of a @@ version. Why is that? What functionally is the difference between having no .symver and a .symver with an @ version? (I tried both, and they *both* result in undefined symbol errors from ld(1), as I expected. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
