Patch for msvccompiler.py (Win32)
Here's a patch for distutils/msvccompiler.py to ensure that the appropriate Python import library (e.g. "python15.lib" or "python15_d.lib") is linked in with your extension DLL on Windows. As my comment indicates, there's probably a cleaner way to pick up the correct library name but this should work for Python 1.5.x and Python 1.6. Index: msvccompiler.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/msvccompiler.py,v retrieving revision 1.25 diff -c -r1.25 msvccompiler.py *** msvccompiler.py 2000/03/31 19:04:25 1.25 --- msvccompiler.py 2000/04/12 22:43:28 *************** *** 329,334 **** --- 329,346 ---- extra_preargs=None, extra_postargs=None): + # Add the Python library to the standard library list. + # There's probably a more elegant way to determine the correct name ;) + if sys.winver == '1.5': + pythonlib = 'python15' + else: + pythonlib = 'python16' + + if debug: + pythonlib = pythonlib + '_d' + + self.add_library(pythonlib) + (objects, output_dir) = self._fix_object_args (objects, output_dir) (libraries, library_dirs, runtime_library_dirs) = \ self._fix_lib_args (libraries, library_dirs, runtime_library_dirs)
Here's a patch for distutils/msvccompiler.py to ensure that the appropriate Python import library (e.g. "python15.lib" or "python15_d.lib") is linked in with your extension DLL on Windows. I never had any problems with this: the Python header files ensure this by a pragma. You (or distutils) don't have to care about this.
Thomas Heller
Now that you mention it, that does sound familiar ;) Nevertheless, when I started trying to use the Distutils-0.8 distro to build my Python extension under Windows it came up with numerous unresolved symbols (Python library calls) until I used this modification to actually list python15.lib (or python15_d.lib) on the link line. I'll investigate this some more today to see if I can figure out what's going wrong here.
-----Original Message----- From: Thomas Heller [mailto:thomas.heller@ion-tof.com] Sent: Thursday, April 13, 2000 3:05 AM To: Lyle Johnson; distutils-sig@python.org Subject: Re: [Distutils] Patch for msvccompiler.py (Win32)
Here's a patch for distutils/msvccompiler.py to ensure that the appropriate Python import library (e.g. "python15.lib" or "python15_d.lib") is linked in with your extension DLL on Windows. I never had any problems with this: the Python header files ensure this by a pragma. You (or distutils) don't have to care about this.
Thomas Heller
[Lyle Johnson]
Here's a patch for distutils/msvccompiler.py to ensure that the appropriate Python import library (e.g. "python15.lib" or "python15_d.lib") is linked in with your extension DLL on Windows.
msvccompiler.py is not the right sort of place for patches like this; I'm trying to keep the *CCompiler classes from being specific to building Python extensions. Or rather, from getting any more specific to building Python extensions than they already are (he says, having just poked through unixccompiler.py to see what it imports from sysconfig). But the point is moot: [Thomas Heller]
I never had any problems with this: the Python header files ensure this by a pragma. You (or distutils) don't have to care about this.
It has just occurred to me that those pragmas are awfully handy things, but can we rely on them? What if someone wants to build Python extensions with the Windows port of gcc, or with Borland's newly free-as-in-free-beer compiler? (I imagine they'll have a big job, as they'll probably have to start with building Python itself with said compiler. But this might be yet another little problem along that road.) IOW, perhaps build_ext.py should have yet another bit of Windows-specific code -- not MSVC-specific this time, but Windows-specific -- to (maybe) add the Python DLL to the link. Thoughts? Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ Disclaimer: All rights reserved. Void where prohibited. Limit 1 per customer.
It has just occurred to me that those pragmas are awfully handy things, but can we rely on them?
In my experience, we can rely on them more than users specifying the correct libraries! Particularly with version changes, and debug/release builds. This may or may not be relevant to distutils. Also, any .libs specified on the command line will be searched before onces specified by the pragmas - meaning the command line effectively overrides it.
What if someone wants to build Python extensions with the Windows port of gcc, or with Borland's newly free-as-in-free-beer compiler? (I imagine they'll have a big job, as they'll probably have to start with building Python itself with said compiler. But this might be yet another little problem along that road.)
If they dont support the pragma (which I bet they will), then it is simply #ifdef'd around an MS specific variable. I think this would be the least of their problems! Mark.
participants (4)
-
Greg Ward -
Lyle Johnson -
Mark Hammond -
Thomas Heller