----- Original Message -----
From: "Vít Ondruch" <vondruch(a)redhat.com>
Sent: Friday, November 8, 2019 10:01:47 AM
Subject: Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link
with libpython3.8.a for better
Dne 07. 11. 19 v 23:08 Florian Weimer napsal(a):
> * Vít Ondruch:
>> Dne 07. 11. 19 v 16:05 Tom Hughes napsal(a):
>>> On 07/11/2019 14:59, Victor Stinner wrote:
>>>> I cannot explain why PLT is needed when a libpython function calls a
>>>> libpython function.
>>> Because an exported symbol in an ELF shared library is subject to
>>> potential interposition using LD_PRELOAD so the calls need to go
>>> through the PLT to be resolved.
>> Not sure what PLT is (pre load table?), but is it something what could
>> be disabled?
> Procedure Linkage Table.
> It can be disabled by using hidden symbols. For internal symbols, that
> is easy. For symbols that are used externally, I do not think we have
> good toolchain support. Link-time optimization can detect truly
> internal symbols and make them hidden. Some targets can also perform
> relaxation of relocations, eliminating most of the PLT indirection
> overhead if it turns out a function is not exported after all and
> therefore cannot be interposed. But that needs a version script, and it
> can't work for calls to functions that are in fact public.
> In glibc, we create hidden aliases for public functions which should not
> be interposed. It's not too bad if you have preprocessor macros for
> this task, but you do need to annotate each function declaration and
> definition separately.
>> This sounds like the whole system could be 25% faster if we link
> Not reallly, quite a few system components already do this kind of
> Toolchain support for this is quite poor however. Ideally, we would
> have a compilation mode that reuses the annotations that Windows uses,
> but given that our system headers currently lack __dllimport specifiers
> (or whatever they are called), even with that approach, it's quite a lot
> of work. I might be mistaken about this, but I think there was a huge
> conflict about some intermediate visibility setting (protected?) that
> might help with this, basically creating non-interposable function
> symbols, but I don't think it's usable for that in its current state.
Thx for explanation Florian.
Generally, I am against this change proposal, because:
1) Apparently, there is some work which needs to be done on the
toolchain. Applying workarounds just hides the issues and we won't move
I think it's more reasonable to do a small SPEC change in Python to achieve a 27%
performance boost, than wait for the toolchain to catch up on things that are not well
defined yet. I don't see that as a valid reason for not accepting the change, although
you might want to elaborate further here.
2) I am asking this questions, because I believe that the same issue
might suffer Ruby and others are concerned about Perl. Applying this
just to Python is not systematic.
Maybe. Systematic or not when compared to other dynamic languages is not really relevant
for this change to take effect. I don't know about Perl's or Ruby's
architecture design, but is there a reason to keep them in line in that aspect? Or for any
other aspect at all, apart from the general packaging guidelines?
However, if part of this change proposal was actually collecting the
information what have to be done to have similar performance for the
dynamically linked libraries comparing to static linking, if there is
push to improve the toolchain and if there is generally better
understanding of the issue, then I would not mind if this is accepted as
temporary measure. Unfortunately, nothing like this is mentioned in the
No this is not intended to be temporal, hence why it's not mentioned as such. The
information has been collected as a case for the change. If other languages would like to
conduct similar benchmarks and experiments they are free to do so, but the scope of this
change is just for Python. Also it's not intended as a push for certain toolchain
changes/optimizations, although thet would be more than welcome. In addition this change
is not a case for the benefits of static linking in general, as we are not aware or
experimented on other things, we outlined a specific case, which is in line with the
packaging guidelines, since statically linking a binary against its own library is
This change intends to speed up Python by a significant margin in the context of the
current toolchain, with the outlined effects on compatibility and package changes. We can
debate on that, the rest seem irrelevant in the context of accepting it or not.
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Python Maintenance Team, Red Hat