[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for
From:       Aleksandra Fedorova <alpha () bookwar ! info>
Date:       2019-11-15 12:24:23
Message-ID: CAJ2r3Z2R_oe0fcootk=7DAK1d3R0x+0UnKXCjH2vSR0CWKRywg () mail ! gmail ! com
[Download RAW message or body]

Hi

On Fri, Nov 15, 2019 at 10:22 AM Victor Stinner <vstinner@redhat.com> wrote:
> 
> Hi Jan,
> 
> With the helper of Florian Weimer and Charalampos Stratakis, we also agreed to test \
> this flag in priority. I understood that it disables the LD_PRELOAD feature: it's \
> no longer possible to override symbols in libpython with LD_PRELOAD. Thanks to \
> that, the compiler can avoid PLT indirection for function calls and can inline more \
> function functions in libpython. I'm talking about a function call from libpython \
> to libpython: something which is very common in python. Basically, almost all \
> function calls are calls from libpython to libpython. 
> I'm impressed. Thanks to -fno-semantic-interposition, I get the same speedup on a \
> dynamically linked Python (libpython) compared to statically linked Python! 
> Yesterday, I tried on a vanilla Python compiled manually:
> 
> ./configure --enable-optimizations --with-lto --enable-shared
> CFLAGS="-fno-semantic-interposition" LDFLAGS="-fno-semantic-interposition"
> 
> I saw the same speed up than avoiding --enable-shared. Today I validated this \
> result using the RPM generated by Charalampos's PR: \
> https://src.fedoraproject.org/rpms/python38/pull-request/53 
> In short, https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup is useless: \
> there is no need to modify Python to statically link it to libpython. We can keep \
> the dynamically library libpython and keep Python dynamically linked to it. We only \
> need to pass -fno-semantic-interposition to compiler and linker flags when building \
> Python! 
> 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.

Please do file a Change. It works not only as a coordination tracker,
but also as a tool to inform everyone about changes happening in
Fedora.

The discussion on the topic has been very interesting, as well as the
outcome. I think it would be nice to see the summary with the
estimated impact and highlight it via Release Notes.

> If someone really needs LD_PRELOAD, it's quite easy to build a custom Python \
> without -fno-semantic-interposition. 
> Victor
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> 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@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org



[prev in list] [next in list] [prev in thread] [next in thread]