On 2/4/2013 12:59 PM, David Cournapeau wrote:
On Mon, Feb 4, 2013 at 8:27 PM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
On Sun, Feb 3, 2013 at 2:57 AM, David Cournapeau <cournape@gmail.com> wrote:
On Sun, Feb 3, 2013 at 12:28 AM, <josef.pktd@gmail.com> wrote:
On Sat, Feb 2, 2013 at 6:14 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I see there is no Windows 64 bit installer for the 1.7 rc1.
related: Is there any chance to get newer mingw or mingw-w64 support "soonish"?
The problem has no solution until we can restrict support to windows 7 and above. Otherwise, any acceptable solution would require user to be an admin.
The installer is built with this VM/scripts:
I am not sure whether you're replying to my observation or just giving a status update: with mingw-w64 (or recent mingw), the built installer will depend on several .dll (libgcc_s_sjil.dll) that we can't easily distribute. The only place we can realistically put them is in C:\Python$VERSION (or wherever python happens to be installed), and I think it is a very bad idea to install dll from NumPy there. In Windows 2008 and above, one can refer in .pyd where to look for dlls in another directory which is private to numpy.
David
If I understand correctly the problem is distributing dependency/runtime DLLs with a package and ensuring the DLLs are found by Windows when the pyd extensions are imported? For numpy-MKL and other packages I include/install the extra DLLs in the package directories and, if necessary, (i) append the package directory to os.environ['PATH'] or (ii) "pre-load" the DLLs into the process using Ctypes, both early in the package's main __init__.py. No admin rights are required. Christoph