On Fri, 2019-11-15 at 12:31 +0000, Daniel P. Berrangé wrote: > On Fri, Nov 15, 2019 at 01:23:09PM +0100, Miroslav Suchý wrote: > > Dne 15. 11. 19 v 10:21 Victor Stinner napsal(a): > > > I'm not sure if we need a Fedora change just for a compiler flag. > > > Again, the only drawback is that we will no longer be able to > > > override a symbol using LD_PRELOAD. Honestly, I never did that. I > > > don't see any use case for that. But I used LD_PRELOAD on the > > > libc multiple times to mock the system clock for example. > > > > > > If someone really needs LD_PRELOAD, it's quite easy to build a > > > custom Python without -fno-semantic-interposition. > > > > Mock's Nosync plugin use LD_PRELOAD: > > https://github.com/rpm-software-management/mock/wiki/Feature-nosync > > IIUC mock would not be affected by this change. > > The LD_PRELOAD limitation described applies to symbols that are in > the libpython.so library. > > Those docs suggest mock is replacing the fsync() API in glibc with > its > LD_PRELOAD, so that should continue to work as normal. > > Regards, > Daniel Thinking aloud: does anyone ever use symbol overriding for anything other than glibc? What would it do to distro-wide performance if -fno-semantic-interposition were added to the default rpm build flags, (and glibc added -fsemantic- interposition to override this)? Basically, change the default distro-wide to libraries opting-in to being able to be interposed, rather than opting-out (-fsemantic- interposition appears to be on by default, looking at the source for gcc). Would other workloads get benefit? How much would break? (Not that I'm volunteering to run the experiment myself) Hope this is constructive Dave _______________________________________________ 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
