Dne 15. 11. 19 v 15:51 David Malcolm napsal(a): > 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). +1 Because this was from the beginning my concern. Why do it just for Python if possibly the whole distribution could benefit. Vít > > 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 _______________________________________________ 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