[Numpy-discussion] Any plans for windows 64-bit installer for 1.7?
Mon Feb 4 17:49:15 CST 2013
On 2/4/2013 12:59 PM, David Cournapeau wrote:
> On Mon, Feb 4, 2013 at 8:27 PM, Ondřej Čertík <firstname.lastname@example.org> wrote:
>> On Sun, Feb 3, 2013 at 2:57 AM, David Cournapeau <email@example.com> wrote:
>>> On Sun, Feb 3, 2013 at 12:28 AM, <firstname.lastname@example.org> wrote:
>>>> On Sat, Feb 2, 2013 at 6:14 PM, Matthew Brett <email@example.com> wrote:
>>>>> I see there is no Windows 64 bit installer for the 1.7 rc1.
>>>> 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.
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
More information about the NumPy-Discussion