[Python-Dev] Re: How official binaries are built?
> On 17 Oct 2019, at 08:13, Inada Naoki wrote: > > Thank you for your response. > And I'm sorry about ignoring this. Gmail marked it as spam. > > On Tue, Oct 15, 2019 at 6:20 PM Ned Deily wrote: >> >> We currently do not use those options to build the binaries for the >> python.org macOS installers. The main reason is that the Pythons we provide >> are built to support a wide-range of macOS releases and to do so safely we >> build the binaries on the oldest version of macOS supported by that >> installer. So, for example, the 10.9+ installer variant is built on a 10.9 >> system. Some of the optimization features either aren't available or are >> less robust on older build tools. > > It makes sense. Somewhat. I would be better to build with the latest compiler because that’s generally better than older compilers, but that requires some source changes and testing to ensure that the build still works on older versions of macOS. At this point in time nobody seems to have available time and need to work on this, including myself. Ronald ___ 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/ZXJ4OJV7YWKCUX6NOYD5IGP4MNOMOCYM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Setting frame evaluation function (i.e.:PyInterpreterState.frame_eval)
On Wed, Oct 16, 2019 at 1:05 PM Victor Stinner wrote:
> Would you mind to open an issue at bugs.python.org? You can put me
> ("vstinner") in the nosy list.
>
Done: https://bugs.python.org/issue38500
>
> Victor
>
> Le mer. 16 oct. 2019 à 17:07, Fabio Zadrozny a écrit :
> >
> >
> > On Wed, Oct 16, 2019 at 11:14 AM Victor Stinner
> wrote:
> >>
> >> Hi Fabio,
> >>
> >> Right, the PyInterpreterState structure is now opaque. You need to
> >> include pycore_pystate.h which requires to define the
> >> Py_BUILD_CORE_MODULE macro. That's the internal C API which "should
> >> not be used", but it's ok to use it for very specific use cases, like
> >> debuggers.
> >>
> >> Maybe we should provide an interpreter method to set
> >> interp->eval_frame, to avoid to pull the annoying internal C API.
> >>
> >
> > Hi Victor,
> >
> > Thank you very much, that did the trick!
> >
> > I agree it'd be nicer to have some method to set up the frame evaluation
> function instead of pulling up the internal C API, but it's also *very*
> specialized, so, I'm not sure how much it's worth it (I'm happy with just
> being able to do it, even if it's not very straightforward).
> >
> > Best Regards,
> >
> > Fabio
> >
> >> Le mer. 16 oct. 2019 à 15:47, Fabio Zadrozny a
> écrit :
> >> >
> >> > Hi All,
> >> >
> >> > I'm trying to upgrade the pydevd debugger to the latest version of
> CPython (3.8), however I'm having some issues being able to access
> `PyInterpreterState.eval_frame` when compiling, so, I'd like to ask if
> someone can point me in the right direction.
> >> >
> >> > What I'm trying to do is compile something like:
> >> >
> >> > #include "pystate.h"
> >> > ...
> >> > PyThreadState *ts = PyThreadState_Get();
> >> > PyInterpreterState *interp = ts->interp;
> >> > interp->eval_frame = my_frame_eval_func;
> >> >
> >> > and the error I'm having is:
> >> >
> >> > _pydevd_frame_eval/pydevd_frame_evaluator.c(7534): error C2037: left
> of 'eval_frame' specifies undefined struct/union '_is'
> >> >
> >> > So, it seems that now "pystate.h" only has a forward reference to
> "_is" and a typedef from " PyInterpreterState" to "_is" and "_is" is
> defined in "include/internal/pycore_pystate.h", which doesn't seem like I
> should be including (in fact, if I try to include it I get an error saying
> that I would need to define Py_BUILD_CORE)... so, can someone point me to
> the proper way to set the frame evaluation function on CPython 3.8?
> >> >
> >> > Thanks,
> >> >
> >> > Fabio
> >> > ___
> >> > 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/BJAO35DB4KDC2EWV553YEU3VLRNYJSQ6/
> >> > Code of Conduct: http://python.org/psf/codeofconduct/
> >>
> >>
> >>
> >> --
> >> Night gathers, and now my watch begins. It shall not end until my death.
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
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/JCFM5I4UHQ2ZZCOQ5GWWWTKWIXPZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP for libffi + _ctypes
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-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/PPAN5U3VXQ6GDQFQE6TPGEPWTK7WRJZY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 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 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 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-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/PPAN5U3VXQ6GDQFQE6TPGEPWTK7WRJZY/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/BA6BPUSVWUZFRW7C24RDTWYN7FGEG2VA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP for libffi + _ctypes
> -Original Message- > From: Victor Stinner > Sent: Thursday, October 17, 2019 10:06 AM > To: Kacvinsky, Tom > 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-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/A34TOQS5XBMWO5Q7AOPXDFEI3DDXAUBP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP for libffi + _ctypes
- Original Message - > From: "Tom Kacvinsky" > 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 > > Sent: Thursday, October 17, 2019 10:06 AM > > To: Kacvinsky, Tom > > 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-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/A34TOQS5XBMWO5Q7AOPXDFEI3DDXAUBP/ > 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 -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/ISYRGFJWYXNEPWS6S25URB3U2PPVFBT3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP for libffi + _ctypes
Hi, > -Original Message- > From: Charalampos Stratakis > Sent: Thursday, October 17, 2019 11:26 AM > To: Kacvinsky, Tom > Cc: python-dev@python.org > Subject: Re: [Python-Dev] Re: PEP for libffi + _ctypes > > 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/
