On 15. 11. 19 16:20, Vít Ondruch wrote:
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.
I'm not saying we shouldn't. It's a good idea (to explore).
Why not start with Python and if it proves working, continue form there?
The benefit is that in Python, we would handle the Python change and the revert
would be just one package, in case unforeseen problems occur.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
