Hi,
-----Original Message----- From: Charalampos Stratakis <cstratak@redhat.com> Sent: Thursday, October 17, 2019 11:26 AM To: Kacvinsky, Tom <Tom.Kacvinsky@vector.com> Cc: python-dev@python.org Subject: Re: [Python-Dev] Re: PEP for libffi + _ctypes
<snip>
Well RHEL5 doesn't include libffi in its default repos, however you can find it from the EPEL5 repositories.
Also available directly through the fedora build system [0].
It seems that you are asking for libffi to continue to be bundled with cpython upstream, however if you are compiling python from source, why is it a hassle to install an rpm from the EPEL repos? Is it some form of installer/scripts/automation?
Internally, this is fine, but we bundle an embedded Python interpreter in our product, which runs on all kinds of different flavors/versions of Linux. Suppose I use the EPEL repository for CentOS 5 ,which I just did a few minutes ago. Then I dynamically link against libffi.so.5. Now, _ctypes will depend on libffi.so.5, but what happens if a customer runs on a distribution/version of Linux that has only libffi.so.6? Then _ctypes won't load. That's no good at all, _ctypes is crucial for some of our code. The above is why I want to bundle libffi - either statically linked in or dynamically. In the latter case, we would ship the libffi shared library for consistency amongst Linux distributions. I hope that makes it clearer what my concern is, and the motivation for doing what I want to do. Regards, Tom