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.
Indeed, it would be a massive scope creep compared to your feature; I
just thought it worth mentioning as an idea - I don't want to derail
your work (and thanks for speeding up python!)
Dave