On Wed, Apr 2, 2014 at 7:52 AM, Matthew Brett <matthew.br...@gmail.com>wrote:
> Hi, > > On Tue, Apr 1, 2014 at 4:46 PM, David Cournapeau <courn...@gmail.com> > wrote: > > > > > > > > On Wed, Apr 2, 2014 at 12:36 AM, Nathaniel Smith <n...@pobox.com> wrote: > >> > >> On Tue, Apr 1, 2014 at 11:58 PM, David Cournapeau <courn...@gmail.com> > >> wrote: > >> > On Tue, Apr 1, 2014 at 6:43 PM, Nathaniel Smith <n...@pobox.com> > wrote: > >> >> > >> >> On Tue, Apr 1, 2014 at 6:26 PM, Matthew Brett < > matthew.br...@gmail.com> > >> >> wrote: > >> >> > I'm guessing that the LOAD_WITH_ALTERED_SEARCH_PATH means that a > DLL > >> >> > loaded via: > >> >> > > >> >> > hDLL = LoadLibraryEx(pathname, NULL, > LOAD_WITH_ALTERED_SEARCH_PATH); > >> >> > > >> >> > will in turn (by default) search for its dependent DLLs in their > own > >> >> > directory. Or maybe in the directory of the first DLL to be > loaded > >> >> > with LOAD_WITH_ALTERED_SEARCH_PATH, damned if I can follow the > >> >> > documentation. Looking forward to doing my tax return after this. > >> >> > > >> >> > But - anyway - that means that any extensions in the DLLs directory > >> >> > will get their dependencies from the DLLs directory, but that is > only > >> >> > true for extensions in that directory. > >> >> > >> >> So in conclusion, if we just drop our compiled dependencies next to > >> >> the compiled module files then we're good, even on older Windows > >> >> versions? That sounds much simpler than previous discussions, but > good > >> >> news if it's true... > >> > > >> > > >> > That does not work very well in my experience: > >> > > >> > - numpy has extension modules in multiple directories, so we would > >> > need to > >> > copy the dlls in multiple subdirectories > >> > - copying dlls means that windows will load that dll multiple times, > >> > with > >> > all the ensuing problems (I don't know for MKL/OpenBlas, but we've > seen > >> > serious issues when doing something similar for hdf5 dll and > >> > pytables/h5py). > >> > >> We could just ship all numpy's extension modules in the same directory > >> if we wanted. It would be pretty easy to stick some code at the top of > >> numpy/__init__.py to load them from numpy/all_dlls/ and then slot them > >> into the appropriate places in the package namespace. > >> > >> Of course scipy and numpy will still both have to ship BLAS etc., and > >> so I guess it will get loaded at least twice in *any* binary install > >> system. I'm not sure why this would be a problem (Windows, unlike > >> Unix, carefully separates DLL namespaces, right?) > > > > > > It does not really matter here. For pure blas/lapack, that may be ok > because > > the functions are "stateless", but I would not count on it either. > > > > The cleanest solution I can think of is to have 'privately shared DLL', > but > > that would AFAIK require patching python, so not really an option. > > David - do you know anything about private assemblies [1]? > I never managed to make that work properly. > Might they work for our problem? How about AddDllDirectory [2]? > I don't think it is appropriate to use those functions in a C extension module (as it impacts the whole process). David > > Cheers, > > Matthew > > [1] > http://msdn.microsoft.com/en-us/library/windows/desktop/ff951638(v=vs.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/windows/desktop/hh310513(v=vs.85).asp > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
