Basically you need:
(1) site.cfg or %HOME%\.numpy-site.cfg with the following content: (change
the paths according to your installation)
[openblas]
libraries = openblas
library_dirs = D:/devel/packages/openblas/amd64/lib
include_dirs = D:/devel/packages/openblas/amd64/include
OpenBLAS was build
Two quick comments:
- You need MSYS or Cygwin to build OpenBLAS. MSYS has uname and perl. Carl
probably used MSYS.
- BLAS and LAPACK are Fortran libs, hence there are no header files. NumPy
and SciPy include their own cblas headers.
Sturla
Olivier Grisel wrote:
> Hi Carl,
>
> Could you please
Hi Carl,
Could you please provide some details on how you used your
mingw-static toolchain to build OpenBLAS, numpy & scipy? I would like
to replicate but apparently the default Makefile in the openblas
projects expects unix commands such as `uname` and `perl` that are not
part of your archive. Di
Hi,
On Tue, Jan 27, 2015 at 1:37 PM, Carl Kleffner wrote:
>
>
> 2015-01-27 22:13 GMT+01:00 Nathaniel Smith :
>>
>> On Tue, Jan 27, 2015 at 8:53 PM, Ralf Gommers
>> wrote:
>> >
>> > On Mon, Jan 26, 2015 at 4:30 PM, Carl Kleffner
>> > wrote:
>> >>
>> >> Thanks for all your ideas. The next version
2015-01-27 22:13 GMT+01:00 Nathaniel Smith :
> On Tue, Jan 27, 2015 at 8:53 PM, Ralf Gommers
> wrote:
> >
> > On Mon, Jan 26, 2015 at 4:30 PM, Carl Kleffner
> wrote:
> >>
> >> Thanks for all your ideas. The next version will contain an augumented
> >> libopenblas.dll in both numpy and scipy. On
On Tue, Jan 27, 2015 at 10:13 PM, Nathaniel Smith wrote:
> On Tue, Jan 27, 2015 at 8:53 PM, Ralf Gommers
> wrote:
> >
> > On Mon, Jan 26, 2015 at 4:30 PM, Carl Kleffner
> wrote:
> >>
> >> Thanks for all your ideas. The next version will contain an augumented
> >> libopenblas.dll in both numpy
On Tue, Jan 27, 2015 at 8:53 PM, Ralf Gommers wrote:
>
> On Mon, Jan 26, 2015 at 4:30 PM, Carl Kleffner wrote:
>>
>> Thanks for all your ideas. The next version will contain an augumented
>> libopenblas.dll in both numpy and scipy. On the long term I would prefer an
>> external openblas wheel pa
On Mon, Jan 26, 2015 at 4:30 PM, Carl Kleffner wrote:
> Thanks for all your ideas. The next version will contain an augumented
> libopenblas.dll in both numpy and scipy. On the long term I would prefer
> an external openblas wheel package, if there is an agreement about this
> among numpy-dev.
>
On 27-Jan-15 5:32 AM, Carl Kleffner
wrote:
2015-01-27 0:16 GMT+01:00 Sturla Molden :
On 26/01/15 16:30, Carl Kleffner wrote:
Thanks for all your ideas. The next version will contain an augumented
libopenblas.dll in both nu
On 27/01/15 11:32, Carl Kleffner wrote:
> OpenBLAS in the test wheels is build with DYNAMIC_ARCH, that is all
> assembler based kernels are included and are choosen at runtime.
Ok, I wasn't aware of that option. Last time I built OpenBLAS I think I
had to specify the target CPU.
> Non
> optimi
2015-01-27 0:16 GMT+01:00 Sturla Molden :
> On 26/01/15 16:30, Carl Kleffner wrote:
>
> > Thanks for all your ideas. The next version will contain an augumented
> > libopenblas.dll in both numpy and scipy. On the long term I would
> > prefer an external openblas wheel package, if there is an agre
On 26/01/15 16:30, Carl Kleffner wrote:
> Thanks for all your ideas. The next version will contain an augumented
> libopenblas.dll in both numpy and scipy. On the long term I would
> prefer an external openblas wheel package, if there is an agreement
> about this among numpy-dev.
Thanks for all
Thanks for all your ideas. The next version will contain an augumented
libopenblas.dll in both numpy and scipy. On the long term I would prefer
an external openblas wheel package, if there is an agreement about this
among numpy-dev.
Another idea for the future is to conditionally load a debug ver
On 25/01/15 22:15, Matthew Brett wrote:
> I agree, that shipping openblas with both numpy and scipy seems
> perfectly reasonable to me - I don't think anyone will much care about
> the 30M, and I think our job is to make something that works with the
> least complexity and likelihood of error.
Ye
+1 for bundling OpenBLAS both in scipy and numpy in the short term.
Introducing a new dependency project for OpenBLAS sounds like a good
idea but this is probably more work.
--
Olivier
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://
Hi,
On Sun, Jan 25, 2015 at 12:23 PM, Nathaniel Smith wrote:
> On 25 Jan 2015 18:46, "Carl Kleffner" wrote:
>>
>> 2015-01-25 16:46 GMT+01:00 Nathaniel Smith :
>>>
>>> On Sat, Jan 24, 2015 at 5:29 PM, Carl Kleffner
>>> wrote:
>>> >
>>> > 2015-01-23 0:23 GMT+01:00 Nathaniel Smith :
>>> >>
>>> >>
On 25 Jan 2015 18:46, "Carl Kleffner" wrote:
>
> 2015-01-25 16:46 GMT+01:00 Nathaniel Smith :
>>
>> On Sat, Jan 24, 2015 at 5:29 PM, Carl Kleffner
wrote:
>> >
>> > 2015-01-23 0:23 GMT+01:00 Nathaniel Smith :
>> >>
>> >> On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner
>> >> wrote:
>> >> > OpenBLAS
2015-01-25 16:46 GMT+01:00 Nathaniel Smith :
> On Sat, Jan 24, 2015 at 5:29 PM, Carl Kleffner
> wrote:
> >
> > 2015-01-23 0:23 GMT+01:00 Nathaniel Smith :
> >>
> >> On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner
> >> wrote:
> >> > OpenBLAS is deployed as part of the numpy wheel. That said, the s
On Sat, Jan 24, 2015 at 5:29 PM, Carl Kleffner wrote:
>
> 2015-01-23 0:23 GMT+01:00 Nathaniel Smith :
>>
>> On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner
>> wrote:
>> > OpenBLAS is deployed as part of the numpy wheel. That said, the scipy
>> > wheels
>> > mentioned above are dependant on the ins
Carl Kleffner wrote:
> I very much prefer dynamic linking to numpy\core\libopenblas.dll instead of
> static linking to avoid bloat. This matters, because libopenblas.dll is a
> heavy library (around 30Mb for amd64). As a consequence all packages with
> dynamic linkage to OpenBLAS depend on numpy
On 24-Jan-15 12:14 PM, Carl Kleffner wrote:
> Just a wild guess:
>
> (1) update your pip and try again
Thanks. My pip version was 1,5,6, it is now 6.0.6
>
> (2) use the bitbucket wheels with:
> pip install --no-index -f
> https://bitbucket.org/carlkl/mingw-w64-for-python/downloads numpy
Successfu
2015-01-23 0:23 GMT+01:00 Nathaniel Smith :
> On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner
> wrote:
> > I took time to create mingw-w64 based wheels of numpy-1.9.1 and
> scipy-0.15.1
> > source distributions and put them on
> > https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well
Just a wild guess:
(1) update your pip and try again
(2) use the bitbucket wheels with:
pip install --no-index -f
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads numpy
pip install --no-index -f
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads scipy
(3) check if there i som
On 22-Jan-15 6:23 PM, Nathaniel Smith wrote:
> On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner wrote:
>> I took time to create mingw-w64 based wheels of numpy-1.9.1 and scipy-0.15.1
>> source distributions and put them on
>> https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well as on
2015-01-23 9:25 GMT+01:00 Carl Kleffner :
> All tests for the 64bit builds passed.
Thanks very much Carl. Did you have to patch the numpy / distutils
source to build those wheels are is this using the source code from
the official releases?
--
Olivier
http://twitter.com/ogrisel - http://github.c
All tests for the 64bit builds passed.
Carl
2015-01-23 0:11 GMT+01:00 Sturla Molden :
> Were there any failures with the 64 bit build, or did all tests pass?
>
> Sturla
>
>
> On 22/01/15 22:29, Carl Kleffner wrote:
> > I took time to create mingw-w64 based wheels of numpy-1.9.1 and
> > scipy-0.1
Thanks,
Colin W.
On 22-Jan-15 5:42 PM, Carl Kleffner
wrote:
Yes,
I build win32 as well as amd64 binaries.
Carlkl
2015-01-22 23:06 GMT+01:00 cjw :
Thanks Carl,
This is good to hear. I presume that the AMD64 is covered.
Colin
On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner wrote:
> I took time to create mingw-w64 based wheels of numpy-1.9.1 and scipy-0.15.1
> source distributions and put them on
> https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well as on
> binstar.org. The test matrix is python-2.7 and 3
Were there any failures with the 64 bit build, or did all tests pass?
Sturla
On 22/01/15 22:29, Carl Kleffner wrote:
> I took time to create mingw-w64 based wheels of numpy-1.9.1 and
> scipy-0.15.1 source distributions and put them on
> https://bitbucket.org/carlkl/mingw-w64-for-python/downloads
Yes,
I build win32 as well as amd64 binaries.
Carlkl
2015-01-22 23:06 GMT+01:00 cjw :
> Thanks Carl,
>
> This is good to hear. I presume that the AMD64 is covered.
>
> Colin W.
>
> On 22-Jan-15 4:29 PM, Carl Kleffner wrote:
>
> I took time to create mingw-w64 based wheels of numpy-1.9.1 and
>
Thanks Carl,
This is good to hear. I presume that the AMD64 is covered.
Colin W.
On 22-Jan-15 4:29 PM, Carl Kleffner
wrote:
I took time to create mingw-w64 based wheels of numpy-1.9.1 and
scipy-0.15.1 source distributions and put them on
https
I took time to create mingw-w64 based wheels of numpy-1.9.1 and
scipy-0.15.1 source distributions and put them on
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well as on
binstar.org. The test matrix is python-2.7 and 3.4 for both 32bit and
64bit.
Feedback is welcome.
The wheels
32 matches
Mail list logo
