> Not fool proof checked, but I believe this is what would happen. Usually > one wants to only LD_PRELOAD to replace some glibc symbol, for some kind > of debug, but any library where there valid usages of LD_PRELOAD should > not be linked with -Bdynamic-functions. Having experienced the frustration of dealing with -Bsymbolic first-hand I would strongly discourage adding that kind of link behavior downstream, and if it happens to come from upstream I would strongly advocate to encourage the upstream project to drop it. Once a symbol is extern (or public if you prefer) it's very inconvenient to only be able to catch *some* calls to that symbol. One real-world use case I had for some $DAYJOB was lock contention on the happy path during error checking. For the sake of the argument let's call it libcontended... For the few customers that would run into this corner case that would bring their setup to a crawl, we devised a simple hook with LD_PRELOAD to keep track of errors and force an early return in the offending error checking code to avoid taking the lock when we knew for a fact that it wouldn't return anything anyway. I voluntarily skip other gory details, but we knew that our workaround was correct because we had access to the source code of libcontended (free software, am I right?) but weren't in a position where we could repackage that library. And since that lock contention problem was solved in the next major release, we knew that at some point as customers would eventually upgrade and leave the workaround behind. All was well and fine until we ran into one supported OS where libcontended was patched downstream with -Bsymbolic enabled. The simple workaround that required us to hook two functions was no longer working and not only that, it took us a fair amount of dumbfounding time trying to figure why. We couldn't fix this corner case on that OS. I avoided name dropping on purpose, because I don't want to point fingers, but please, reconsider doing that kind of change. If an application ends up linking to several versions of zlib then something very wrong is going on. Unless that application has some kind of plugin system where two different plugins might bring two different versions of zlib (or for that matter any library). If you are running into that kind of problems where plugins/modules/dynamically linked objects may have conflicting requirements [1] then I would apply the First principle and try to patch the plugin or whatnot that links to an older version to bring it up to speed. If that's indeed a plugin system, it might be possible to isolate conflicting shared objects to some extent with a flag like RTLD_LOCAL. Please take into consideration that resorting to -Bsymbolic might break someone else's use case further downstream, and is technically an ABI breakage. Dridi [1] by the way, equally hard to debug as the case I described above _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
