I have been comiling Python 3.8 from source and have had a really difficult time with getting _ctypes to compile. I see that libffi is no longer distributed with the Python source code, in preference for what is on the system. I searched for a PEP that describes the rationale behind this, but my Google fu must be weak.
I have also seen requests that a patch be committed that makes configuring the use of libffi easier, but as far as I can tell, these have not been committed. It is something I would like to see as I am in a situation where I cannot depend on the system libffi - we support older Linux distributions that don't have libffi - an so I am making a static libffi to be linked in.
Any guidance on this issue would be helpful.
Thanks,
TOm
Hi,
Our bundled copy of libffi has been removed from Python 3.7 by this change which should explain the rationale: https://bugs.python.org/issue27979
Not all Python changes need a PEP. For Windows builds, we provide prebuilt binaries of our dependencies: https://github.com/python/cpython-source-deps/blob/master/README.rst
My notes on Python dependencies: https://pythondev.readthedocs.io/files.html
we support older Linux distributions that don't have libffi
I'm curious, which old Linux distributions don't have libffi? Usually, libffi is preinstalled on Linux, only the development header files are required (a package with a name like "libffi-devel"). Can't you install libffi on these old distributions? IMHO libffi installation should not be the Python problem, bundling a library copy in Python is causing more issues compared to advantages.
Victor
Le jeu. 17 oct. 2019 à 14:52, Kacvinsky, Tom Tom.Kacvinsky@vector.com a écrit :
I have been comiling Python 3.8 from source and have had a really difficult time with getting _ctypes to compile. I see that libffi is no longer distributed with the Python source code, in preference for what is on the system. I searched for a PEP that describes the rationale behind this, but my Google fu must be weak.
I have also seen requests that a patch be committed that makes configuring the use of libffi easier, but as far as I can tell, these have not been committed. It is something I would like to see as I am in a situation where I cannot depend on the system libffi - we support older Linux distributions that don't have libffi - an so I am making a static libffi to be linked in.
Any guidance on this issue would be helpful.
Thanks,
TOm _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PPAN5U3V... Code of Conduct: http://python.org/psf/codeofconduct/
-----Original Message----- From: Victor Stinner vstinner@python.org Sent: Thursday, October 17, 2019 10:06 AM To: Kacvinsky, Tom Tom.Kacvinsky@vector.com Cc: python-dev@python.org Subject: Re: [Python-Dev] PEP for libffi + _ctypes
Hi,
Our bundled copy of libffi has been removed from Python 3.7 by this change which should explain the rationale: https://bugs.python.org/issue27979
Thanks.
Not all Python changes need a PEP. For Windows builds, we provide prebuilt binaries of our dependencies: https://github.com/python/cpython-source-deps/blob/master/README.rst
I am OK with Windows, it is Linux, as below.
My notes on Python dependencies: https://pythondev.readthedocs.io/files.html
Again, thanks for this.
we support older Linux distributions that don't have libffi
I'm curious, which old Linux distributions don't have libffi? Usually, libffi is preinstalled on Linux, only the development header files are required (a package with a name like "libffi-devel"). Can't you install libffi on these old distributions? IMHO libffi installation should not be the Python problem, bundling a library copy in Python is causing more issues compared to advantages.
RHEL/CentOS 5 come to mind. We don't want to get into the use case where we have to have customers install libffi as we try to minimize the hassles our customers might have to go through for installing and using our product.
Tom
----- Original Message -----
From: "Tom Kacvinsky" Tom.Kacvinsky@vector.com To: python-dev@python.org Sent: Thursday, October 17, 2019 4:26:39 PM Subject: [Python-Dev] Re: PEP for libffi + _ctypes
-----Original Message----- From: Victor Stinner vstinner@python.org Sent: Thursday, October 17, 2019 10:06 AM To: Kacvinsky, Tom Tom.Kacvinsky@vector.com Cc: python-dev@python.org Subject: Re: [Python-Dev] PEP for libffi + _ctypes
Hi,
Our bundled copy of libffi has been removed from Python 3.7 by this change which should explain the rationale: https://bugs.python.org/issue27979
Thanks.
Not all Python changes need a PEP. For Windows builds, we provide prebuilt binaries of our dependencies: https://github.com/python/cpython-source-deps/blob/master/README.rst
I am OK with Windows, it is Linux, as below.
My notes on Python dependencies: https://pythondev.readthedocs.io/files.html
Again, thanks for this.
we support older Linux distributions that don't have libffi
I'm curious, which old Linux distributions don't have libffi? Usually, libffi is preinstalled on Linux, only the development header files are required (a package with a name like "libffi-devel"). Can't you install libffi on these old distributions? IMHO libffi installation should not be the Python problem, bundling a library copy in Python is causing more issues compared to advantages.
RHEL/CentOS 5 come to mind. We don't want to get into the use case where we have to have customers install libffi as we try to minimize the hassles our customers might have to go through for installing and using our product.
Tom _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A34TOQS5... Code of Conduct: http://python.org/psf/codeofconduct/
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?
[0] https://koji.fedoraproject.org/koji/buildinfo?buildID=108124
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
-
Charalampos Stratakis -
Kacvinsky, Tom -
Victor Stinner