Hi, > -----Original Message----- > From: Charalampos Stratakis <cstra...@redhat.com> > Sent: Thursday, October 17, 2019 11:26 AM > To: Kacvinsky, Tom <tom.kacvin...@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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/LFC6LOAO6PB3HCQ2LDDPDI62NOLADRM2/ Code of Conduct: http://python.org/psf/codeofconduct/
