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. 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. Or one could leave out all kernels above sandybridge in a dynamic build as long OpenBLAS has errors with newer kernels. > > > BTW: i just now renewed the numpy-1.9.2 and scipy-0.15.0 wheels for > > python-2.6, 2.7, 3.3, 3.4 on anaconda.org. > > 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. > You mean binstar.org right? What did you change in the new > numpy-1.9.2? Have you upgraded OpenBLAS? Which version is embedded by > the way? > anaconda.org is the new replacement for binstar.org as announced in the anaconda ml and should be used right now. Openblas versions contained: 32bit: 3e33afe (june) 64bit: fb02cb0 (april used due to a segfault in the more recent rev) > > I also added scipy-0.16.0rc1 for > > python-2.6, 2.7, 3.3, 3.4. This means I phase out python-3.2 builds for > the > > future. > > I don't think Windows users care about python 3.2 support. > > > python-3.5 support is up in the air right now. > > What do you mean? > > Python-3.5 uses VC 2105 on windows. This compiler uses a complete new variant of CRT libraries. Google for 'universal CRT' to find more information. The mingw-w64 community does not support this right now. I didn't find the time to explore this. Carl -- > Olivier > _______________________________________________ > 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
