1. msvccompiler.py defines a method _find_exe(), but uses find_exe(). 2. The python/libs directory is no longer included in library_dirs when linking extensions. Thomas Heller
On 28 March 2000, Thomas Heller said:
1. msvccompiler.py defines a method _find_exe(), but uses find_exe().
Easy fix -- thanks. Will check it in shortly.
2. The python/libs directory is no longer included in library_dirs when linking extensions.
Hmmm. Was it ever? And why is this necessary? Is it so extensions can link against Python.dll, or is it something else? Anyone out there been following the recent CVS tumult and trying to build stuff on Windows? Thomas (or anyone else on a Windows box with access to the anonymous CVS tree), if you're feeling hardy, you could try rolling back the command/build_ext.py file one revision at a time until either 1) the problem goes away or 2) things blow up horribly because of other incompatibilities. If #2 occurs, try rolling back all of Distutils a week at a time, or maybe 2-3 days at a time. Let me know if you want help with the CVS trickery to do this. Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ A day without sunshine is like night.
On 28 March 2000, Thomas Heller said:
1. msvccompiler.py defines a method _find_exe(), but uses find_exe().
Easy fix -- thanks. Will check it in shortly.
2. The python/libs directory is no longer included in library_dirs when linking extensions.
Hmmm. Was it ever? And why is this necessary? Is it so extensions can link against Python.dll, or is it something else?
Anyone out there been following the recent CVS tumult and trying to build stuff on Windows?
Thomas (or anyone else on a Windows box with access to the anonymous CVS tree), if you're feeling hardy, you could try rolling back the command/build_ext.py file one revision at a time until either 1) the problem goes away or 2) things blow up horribly because of other incompatibilities. If #2 occurs, try rolling back all of Distutils a week at a time, or maybe 2-3 days at a time. Let me know if you want help with the CVS trickery to do this.
Greg
In article <20000328225050.A1109@beelzebub>, Greg Ward
BTW, Is anyone in the NumPy community keeping on top of Distutils? There have been a *lot* of changes since 0.1.3 was released in January, and I have been rather free with making incompatible changes (because there's no way I'm gonna be able to get away with them after Python 1.6/Distutils 1.0 are out). I've also been keeping my examples/numpy_setup.py script up-to-date with the changes, in hopes that some eager NumPy hacker will keep an eye on the changes in Distutils and be ready to update NumPy's real setup script when the time comes. Am I being overly optimistic?
I simply used your examples/numpy_setup.py script with the latest Numeric Python CVS version, and it worked (Solaris 2.6 and RH6.1). There was a message from one frustrated Numeric Python users that didn't care for the pace of changes in distutils, since Numeric Python doesn't ship with a Makefile anymore. But as of this morning (3/28/00), I could grab the latest distutils, install them, copy examples/numpy_setup.py to Numeric/setup.py, and build.
2. The python/libs directory is no longer included in library_dirs when linking extensions.
Hmmm. Was it ever? And why is this necessary? Is it so extensions can link against Python.dll, or is it something else?
Anyone out there been following the recent CVS tumult and trying to build stuff on Windows?
Thomas (or anyone else on a Windows box with access to the anonymous CVS tree), if you're feeling hardy, you could try rolling back the command/build_ext.py file one revision at a time until either 1) the problem goes away or 2) things blow up horribly because of other incompatibilities. If #2 occurs, try rolling back all of Distutils a week at a time, or maybe 2-3 days at a time. Let me know if you want help with the CVS trickery to do this. The problem occurred after cvs revision 1.24 of build_ext.py.
Don't know about unix, but on Windows extensions must be linked against python15.lib (or python15_d.lib if building debug versions). The names of the libraries do not need to be supplied on the command line, they are built with compiler pragmas into the object-files. However they must be found, so the directory must be included in the library search path. msvccompiler.__init__ (on line 162) does this: self.add_library_dir( os.path.join( sys.exec_prefix, 'libs' ) ) (If I understood distutils design philosophy correctly, this probably belongs into build_ext, because it is python extension specific, on the other hand, it may be NT specific). This dir is later *overwritten* in ccompiler.set_library_dirs(), which is called from build_ext, line 185: if self.library_dirs is not None: self.compiler.set_library_dirs (self.library_dirs) Some lines above (line 146) I find the following code: # Simplify the following logic (eg. don't have to worry about # appending to None) if self.libraries is None: self.libraries = [] if self.library_dirs is None: self.library_dirs = [] if self.rpath is None: self.rpath = [] So, if I change the code around line 185 to: if self.library_dirs: self.compiler.set_library_dirs (self.library_dirs) then it works because no library_dirs are specified in the setup_script or from the command line, but IMO the bug is still there. I'll leave it up to you to find the correct fix for this. BTW: Another small bug in build_ext.py: self.build_extensions() should be self.build_extensions (self.extensions) Thomas
participants (3)
-
Greg Ward
-
Robin Becker
-
Thomas Heller