Building Python with VC8 on x64 Vista
Hi all, So I'm working on a C++ application that will eventually embed or extend Python using Boost.Python, but I first need to get Python compiled correctly for my platform. I've got a Windows Vista 64-bit machine with a Core 2 processor, and I'm compiling with a VC8. I downloaded the Python 2.5.1 source from python.org, and I opened the Visual Studio solution file that was in the PCbuild8 directory. I created a new x64 platform and managed to successfully compile the 'pythoncore' and 'python' projects (both in Debug and Release configurations), resulting in working executables. (Aside: When launched, the python console says "Python 2.5.1 [MSC v.1400 64 bit (AMD64)] on win32" up top. Does that seem right?) So, this program I'm writing with Boost.Python (that worked correctly on x86 with home-built libraries) won't compile with these x64 libraries. I keep getting 'unresolved external symbols.' But, I'm certain I'm linking in the library correctly. Here's a snippet from the output (with /verbose:lib) when compiling: 1>Searching libraries 1> 1>Searching ..\..\..\3rdParty\boost_1_34_0\lib_x64\libboost_python- vc80-mt-gy-1_34.lib: 1> 1>Searching ..\..\..\3rdParty\Python25\libs_x64\python25_d.lib: 1>Finished searching libraries 1>py_dyn_test.obj : error LNK2001: unresolved external symbol _Py_NoneStruct 1>vector_py.obj : error LNK2001: unresolved external symbol _Py_NoneStruct 1>volume_py.obj : error LNK2001: unresolved external symbol _Py_NoneStruct 1>py_dyn_test.obj : error LNK2001: unresolved external symbol _Py_RefTotal 1>vector_py.obj : error LNK2001: unresolved external symbol _Py_RefTotal 1>volume_py.obj : error LNK2001: unresolved external symbol _Py_RefTotal 1>volume_py.obj : error LNK2001: unresolved external symbol PyExc_IndexError If I switch to the Release configuration, I see fewer errors: 1>py_dyn_test.obj : error LNK2001: unresolved external symbol _Py_NoneStruct 1>volume_py.obj : error LNK2001: unresolved external symbol PyExc_IndexError Note that none of my own code is Debug-specific. Also, the code in my files is correct, because (as stated above), it worked fine for x86. Though I don't know how useful it is, I did open the python libraries in wordpad, and though most of the file wasn't legible, I did find strings "Py_NoneStruct," "Py_RefTotal," and "PyExc_IndexError." I suspect that I set up my "x64" platform configuration incorrectly, or missed something. It's basically the same as the Win32 configuration, except with the /MACHINE:X64 flag instead of / MACHINE:X86. One of the things I'm noticing just now, as I post this, is that the preprocessor flag "WIN32" is still defined in the x64 configuration. Maybe if I change that to "WIN64," I'll have better luck. Any advice you have on what the "correct" way to do this is would be appreciated. -Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Building Python with VC8 on x64 Vista
On Sep 20, 9:45 am, [EMAIL PROTECTED] wrote: > Hi all, > > So I'm working on a C++ application that will eventually embed or > extend Python using Boost.Python, but I first need to get Python > compiled correctly for my platform. I've got a Windows Vista 64-bit > machine with a Core 2 processor, and I'm compiling with a VC8. > > I downloaded the Python 2.5.1 source from python.org, and I opened the > Visual Studio solution file that was in the PCbuild8 directory. I > created a new x64 platform and managed to successfully compile the > 'pythoncore' and 'python' projects (both in Debug and Release > configurations), resulting in working executables. (Aside: When > launched, the python console says "Python 2.5.1 [MSC v.1400 64 bit > (AMD64)] on win32" up top. Does that seem right?) > > So, this program I'm writing with Boost.Python (that worked correctly > on x86 with home-built libraries) won't compile with these x64 > libraries. I keep getting 'unresolved external symbols.' But, I'm > certain I'm linking in the library correctly. Here's a snippet from > the output (with /verbose:lib) when compiling: > > 1>Searching libraries > 1> > 1>Searching ..\..\..\3rdParty\boost_1_34_0\lib_x64\libboost_python- > vc80-mt-gy-1_34.lib: > 1> > 1>Searching ..\..\..\3rdParty\Python25\libs_x64\python25_d.lib: > 1>Finished searching libraries > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol > _Py_NoneStruct > 1>vector_py.obj : error LNK2001: unresolved external symbol > _Py_NoneStruct > 1>volume_py.obj : error LNK2001: unresolved external symbol > _Py_NoneStruct > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol > _Py_RefTotal > 1>vector_py.obj : error LNK2001: unresolved external symbol > _Py_RefTotal > 1>volume_py.obj : error LNK2001: unresolved external symbol > _Py_RefTotal > 1>volume_py.obj : error LNK2001: unresolved external symbol > PyExc_IndexError > > If I switch to the Release configuration, I see fewer errors: > > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol > _Py_NoneStruct > 1>volume_py.obj : error LNK2001: unresolved external symbol > PyExc_IndexError > > Note that none of my own code is Debug-specific. Also, the code in my > files is correct, because (as stated above), it worked fine for x86. > > Though I don't know how useful it is, I did open the python libraries > in wordpad, and though most of the file wasn't legible, I did find > strings "Py_NoneStruct," "Py_RefTotal," and "PyExc_IndexError." > > I suspect that I set up my "x64" platform configuration incorrectly, > or missed something. It's basically the same as the Win32 > configuration, except with the /MACHINE:X64 flag instead of / > MACHINE:X86. One of the things I'm noticing just now, as I post this, > is that the preprocessor flag "WIN32" is still defined in the x64 > configuration. Maybe if I change that to "WIN64," I'll have better > luck. > > Any advice you have on what the "correct" way to do this is would be > appreciated. > > -Dan I've tried re-building my libraries from the latest revision (58225), using the solution in the PCbuild8 folder. I had no problems getting the python25[_d].lib to compile, but I still get these symbol errors when I try to link with the library. -Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Building Python with VC8 on x64 Vista
On Sep 22, 10:08 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > 1>py_dyn_test.obj : error LNK2001: unresolved external symbol > > _Py_NoneStruct > > Could it be that py_dyn_test.obj is a x86 (not AMD64) object > file? Run dumpbin. Hmm - I've never used dumpbin, but I think I like it. It doesn't look like these are x86, though. See below: D:\\py_dyn_test\x64\Debug>dumpbin /HEADERS py_dyn_test.obj Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file py_dyn_test.obj File Type: COFF OBJECT FILE HEADER VALUES 8664 machine (x64) D:\\3rdParty\Python25\libs>dumpbin /HEADERS python25_d.lib Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file python25_d.lib File Type: LIBRARY FILE HEADER VALUES 8664 machine (x64) 3 number of sections 46F3CED2 time date stamp Fri Sep 21 09:01:54 2007 113 file pointer to symbol table 8 number of symbols 0 size of optional header 0 characteristics Version : 0 Machine : 8664 (x64) TimeDateStamp: 46F3CED2 Fri Sep 21 09:01:54 2007 SizeOfData : 001E DLL name : python25_d.dll Symbol name : _Py_NoneStruct Type : data Name type: name Hint : 900 Name : _Py_NoneStruct -- http://mail.python.org/mailman/listinfo/python-list
Trouble building pywin32 with Visual Studio 2005
Hi everybody... I'm hoping one of you reading this can help me out here. I'm having trouble getting pywin32 to build with Visual Studio 2005. But first, some background. I'm embedding Python in an MFC application. I've manually built Python .lib and .dll files using Visual Studio 2005 from the solution/ project files in the PCBuild8 folder. I've got a totally happy, working Python interpreter in my MFC application. When I use pre-built pywin32 packages, some strange crashes occur. Specifically, if I import win32com.server.register and call the RegisterClasses function, I get a complaint regarding an attempt to free unallocated memory. Now, my theory on this issue is that DLLs like win32api.pyd, which I acquired pre-built, were built with Visual Studio 2003, and they depend on msvcr71.dll. My Python/MFC application, on the other hand, was built with Visual Studio 2005, and is linking with msvcr80.dll. If memory gets allocated through one DLL, and an attempt is made at freeing it in the other DLL, bad things can happen, since the freeing DLL doesn't have any header information on the allocated memory. In order to test this theory (and potentially fix it), I want to re- build the pywin32 stuff using Visual Studio 2005. Now I've never built pywin32, so please excuse any "noobness" from here on out. I downloaded the pywin32-210.zip source from sourceforge. I tried running "setup.py build" per the Readme, and I received the following message. Warning - can't find an installed platform SDK error: Python was built with Visual Studio 2003; extensions must be built with a compiler that can generate compatible binaries. Visual Studio 2003 was not found on this system. if you have Cygwin installed, you can try compiling with MingW32, by passing "-c mingw32" to setup.py. (Note that I don't have the Platform SDK - This is a Vista machine, so I've got what they now are calling the Windows SDK. If it ends up being a problem, I'll tackle it when it shows up) The logical conclusion to jump to from this error message is that pywin32 is trying to build with VS2005, but it thinks that Python was built with VS2003. Well, in a manner of speaking, that is true. I did have a regular Python installation in C:\Python25, straight from one of the MSI installers. That regular Python installation was undoubtedly compiled with VS2003. I guess what I need to do is find a way to replace the default installation, or certain files within it, with stuff I compiled myself using VS2005. I tried replacing all of the python25[_d].dll and python[w][_d].exe files with those that I built, and that isn't helping. I considered creating a Python installer with the msi.py that is included in the Python Source, but that requires pywin32 (according to the README), and that's what I'm trying to build. I tried going through the setup.py code to find out where it is acquiring this "Python was built with Visual Studio 2003" information, but I keep getting lost in the code, so I can't figure out which, if any, file(s) to change/replace. -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble building pywin32 with Visual Studio 2005
> > In order to test this theory (and potentially fix it), I want to re- > > build the pywin32 stuff using Visual Studio 2005. > > That might not be sufficient. You have to rebuild Python itself as well. Either I misunderstand, or you do. If it wasn't clear, I have already rebuilt Python using Visual Studio 2005. > > The logical conclusion to jump to from this error message is that > > pywin32 is trying to build with VS2005, but it thinks that Python was > > built with VS2003. Well, in a manner of speaking, that is true. I did > > have a regular Python installation in C:\Python25, straight from one > > of the MSI installers. That regular Python installation was > > undoubtedly compiled with VS2003. I guess what I need to do is find a > > way to replace the default installation, or certain files within it, > > with stuff I compiled myself using VS2005. I tried replacing all of > > the python25[_d].dll and python[w][_d].exe files with those that I > > built, and that isn't helping. > > That is likely to happen. distutils doesn't actually *check* what CRT > or VC version Python was built with, instead, it *knows*, hardcoded. Oof. Fair enough. > If you know what you are doing, you can override the logic of distutils. > Set up an SDK environment (with LIBRARY, INCLUDE and everything), then > also set the MSSdk environment variable (which should get set if you > use the standard environment batch file from the SDK), and then also > set DISTUTILS_USE_SDK. Then distutils will trust that the environment > you set up works correctly, and will use it without further questioning. I'll see if I can get that working. During my internet searches, I came across a mail/post/blog or two indicating DISTUTILS_USE_SDK does not work in Visual Studio 2005. I'll see what I can do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble building pywin32 with Visual Studio 2005
> > If you know what you are doing, you can override the logic of distutils. > > Set up an SDK environment (with LIBRARY, INCLUDE and everything), then > > also set the MSSdk environment variable (which should get set if you > > use the standard environment batch file from the SDK), and then also > > set DISTUTILS_USE_SDK. Then distutils will trust that the environment > > you set up works correctly, and will use it without further questioning. > > I'll see if I can get that working. During my internet searches, I > came across a mail/post/blog or two indicating DISTUTILS_USE_SDK does > not work in Visual Studio 2005. I'll see what I can do. I didn't have much luck with this. It looks like my solution is going to be to just ignore this problem for now. In most cases, the binary modules one downloads are written well enough that these DLLs aren't going to step on eachother's toes. In fact, I haven't found a function aside from win32com.server.register.RegisterClasses which has the same problem. Now, if everybody moves to VS2008 for Python 3000, this problem would work itself out. :) Thanks for your help, Martin. -Dan -- http://mail.python.org/mailman/listinfo/python-list
