2015-07-10 22:13 GMT+02:00 Carl Kleffner <cmkleff...@gmail.com>: > > > 2015-07-10 19:06 GMT+02:00 Olivier Grisel <olivier.gri...@ensta.org>: >> >> 2015-07-10 16:47 GMT+02:00 Carl Kleffner <cmkleff...@gmail.com>: >> > Hi Olivier, >> > >> > yes, this is all explained in >> > https://github.com/xianyi/OpenBLAS/wiki/Faq#choose_target_dynamic as >> > well. >> > This seems to be necessary for CI systems, right? >> >> The auto detection should work. If not it's a bug and we should find a >> minimalistic reproduction case to report it to the openblas >> maintainers. >> > I have a debug version of libopenblaspy.dll at hand for 32bit architecture, > 64bit I have to build. I propose to build small testcases with python, as > @wernsaar, the main developer of the newer OpenBLAS kernels is able to > handle this.
Done here, feel free to join the discussion: https://github.com/xianyi/OpenBLAS/issues/603 > Debug builds of libopenblaspy.dll can be used as drop in replacement and can > be used to emit a stack trace as long the segfault is thrown from numpy or > OpenBLAS code. DrMingw may be able to catch segfaults from either, I havn't > tried this yet. > >> >> Or we could choose to build openblas for an old architecture that >> should work everywhere like nehalem for instance. > This is a safe solution. Is Nehalem the most common denominator? > Or one could leave out all kernels above > sandybridge in a dynamic build as long OpenBLAS has errors with newer > kernels. Yes that's an option. How do you do that? I cannot find such a build option in the documentation. > The best technical solution IMHO would be to make an extra mingwpy.openblas > python package to load libopenblaspy.dll into the process space, as this > package could be upgraded independant from numpy/scipy. On the other side > this would mean an additionally package dependancy for numpy at least on the > windows platform. Having a windows only dependency on such a wheel sounds fine with me. However that would mean to ensure that the dll is properly loaded in the windows dll search path prior to importing extensions such as numpy.core._dotblas right? Could this be done via adding something to `numpy.__init__.py` such as: ``` if sys.platform == 'win32': try: # Ensure that libopenblaspy.dll can be found prior to # loading numpy.core._dotblas from mingwpy import openblas except: warnings.warn('Failed to load mingwpy's openblas') # import numpy.core stuff here ``` > anaconda.org is the new replacement for binstar.org as announced in the > anaconda ml and should be used right now. Ok I did not know. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
