[Python-Dev] Python 3.7.4, Visual Studio versions for building modules from source
HI, Not sure if this is the right place to ask, but I am trying to build pywin32-224 from source for Python 3.7.4. I think this might be the right list as this seems to be a generic problem I am having, but I want to focus on one particular module. First, I know I could get this via 'pip install', but I want to build from source to see what it takes in terms of the Windows SDK and Visual Studio versions for some other work I am doing. I am using Python 3.7.4, and I have Visual Studio 2017 15.9 (released July of this year). I see this when running 'python setup.y build': error: Microsoft Visual C++ 14.1 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/ I have tried various compilers from that link (VS 2015, VS 2017, and even VS 2019), but no joy. I also have the Windows SDK 8.1 and 10 installed (pywin32 wants the 8.1 SDK) Does anyone have any ideas as to what I am doing wrong, or if there is some weird underlying issue with setuptools and/or distutils? 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/4V3F6GRM4LBOYKXBIMAM47HCLA5J6XG3/
[Python-Dev] Re: Python 3.7.4, Visual Studio versions for building modules from source
> -Original Message- > From: Steve Dower > Sent: Monday, July 22, 2019 11:36 PM > To: Kacvinsky, Tom ; python-dev@python.org > Subject: [Python-Dev] Re: Python 3.7.4, Visual Studio versions for building > modules from source > This is probably not the best place to ask, though I can understand why you > ended up here. Please try this command: > > -m test -v test_distutils -m *get_vc* > > If the tests pass, post to distutils-...@python.org or the Packaging category > on https://discuss.python.org/ > > If the tests fail, post the output into a new bug at https://bugs.python.org/ > along with > > If the tests are skipped, you probably did not install the C++ or "Python > Native Development" options for Visual Studio. You can run "Visual Studio > Installer" from Start to change your installed options. Tests passed once I used the right Visual Studio Command prompt. I was using the x64 Native toolchain command shell. Once I switched to the generic command shell, all is well. Thanks for the lick in the right direction, it got me to thinking that even though the tools are installed, I should try different Visual Studio shells. 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/55WQKH6XGVJS7EOQT3LGXBJE2LA7LSEW/
[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
> -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
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/
[Python-Dev] Fun with Python 3.8 and Qt
Today I discovered the this struct
typedef struct{
const char* name;
int basicsize;
int itemsize;
unsigned int flags;
PyType_Slot *slots; /* terminated by slot==0. */
} PyType_Spec;
with "PyTypeSlot *slots" being on line 190 of object.h causes a problem when
compiled with code that brings in Qt. Qt has macro definitions of slots.
With a cursory preprocessing of the file I was working with, using the handy
gcc options -dM -E, I found that
slots was defined to nothing
#define slots
and hence caused problems when object.h was brought into the mix.
I will try to make a simple reproducer tomorrow. I know this probably could be
solved by header file inclusion re-ordering,
or in some cases #undef'ing slots before including Python.h, but I also thought
the Python dev team would like to know
about this issue.
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/5VRZVIMFB5OMX7SVQCXCH7FT5MCTN26J/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] sqlite3 module and thread-safe SQLite library
We ran into an issue where having the SQLite library built with -DSQLITE_THREADSAFE=0, but then the sqlite3 module (really, the _sqlite3.so0 crashing in threading code. So I have to ask if it is intended that the sqlite3 Python module always be built with a thread safe SQLite library. 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/PKHFTUQSLXWYOZNX4QMSNCPAF5Y3TL2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python2 as 𝑣 → 𝑒
> -Original Message- > From: Mike Miller > Sent: Saturday, April 11, 2020 6:17 PM > To: python-dev@python.org > Subject: [Python-Dev] Python2 as 𝑣 → 𝑒 > > > Unless I've read something wrong, it looks like the final Python 2 release > (2.7.18) should approximate the math constant e: > > >>> import math > >>> math.e > 2.718281828459045 > > Aka: > > Python as 𝑣 → 𝑒 > Python ≈ 𝑒 > > Would be fun to note that in the announcement/docs somehow. Of note, metafont already has the distinction of being versioned after the digits of e, just like TeX is versioned after the digits of pi. ___ 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/NOVIBPPVXFSY7RDGMM3GULQPVDAV3X7U/ Code of Conduct: http://python.org/psf/codeofconduct/
