[Pdl-porters] CHM/PDL-LinearAlgebra-0.06_01.tar.gz uploaded to CPAN

[Chris Marshall]

This CPAN Developers release should build with PDL
versions with and without PDL_Indx support. Needs
to be verified for that.

Also, this fails to build for Strawberry Perl Portable in
the same manner as the latest official 0.06 release.
If you can help diagnose and fix this problem, the help
would be appreciated.

Thanks to Dima for the initial patch for the fix.

--Chris

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall

Post by Chris Marshall
Also, this fails to build for Strawberry Perl Portable in
the same manner as the latest official 0.06 release.
If you can help diagnose and fix this problem, the help
would be appreciated.

It's rather hard to write portable Makefiles.PL that handle this
automatically.
What are the names of the lapack/blas libraries against which to build this
module on Strawberry ?
(Strawberry doesn't ship with these libraries - they need to be built, or
binaries obtained.)

For my Windows builds of PDL::LinearAlgebra, I link to static libraries
liblapack.a and librefblas.a. (I also need to link to libgfortran.a.)
My liblapack.a and librefblas.a are not in a standard location, so I need to
cater for that, too. (This aspect is not generally an issue with
Strawberry.)

The simplest thing for me to do is to hack Complex/Makefile.PL,
Real/Makefile.PL and Trans/Makefile.PL.
It's the same hack for each of those 3 Makefiles.PL. Near the beginning of
the file I insert:

$w32_lib = $Config::Config{archname} =~ /x86/
?
" -LC:\\MinGW\\msys\\1.0\\local\\lib -llapack -lrefblas -LC:/MinGW/lib/gcc/mingw32/4.7.0
-lgfortran "
: " -LC:\\_64\\msys\\1.0\\local\\lib -llapack -lrefblas -lgfortran ";

And I change:

$hash{LIBS}[0] .= $^O =~ /MSWin/ ? '' :
'-L/usr/lib/atlas -llapack -lblas -latlas ';
to
$hash{LIBS}[0] .= $^O =~ /MSWin/ ? "$w32_lib" :
'-L/usr/lib/atlas -llapack -lblas -latlas ';

For 0.06_01, that's all I have to do.

You'd want essentially the same for Strawberry Perl. However, you probably
wouldn't need to assign the paths to $w32_lib. Just make it:

$w32_lib = ' -llapack -lrefblas -lgfortran';

Post by Chris Marshall
Thanks to Dima for the initial patch for the fix.

+1

Cheers,
Rob

[Chris Marshall]

-----Original Message----- From: Chris Marshall

Post by Chris Marshall
Also, this fails to build for Strawberry Perl Portable in
the same manner as the latest official 0.06 release.
If you can help diagnose and fix this problem, the help
would be appreciated.

It's rather hard to write portable Makefiles.PL that handle this
automatically. What are the names of the lapack/blas libraries
against which to build this module on Strawberry ?
(Strawberry doesn't ship with these libraries - they need to
be built, or binaries obtained.)
For my Windows builds of PDL::LinearAlgebra, I link to static libraries
liblapack.a and librefblas.a. (I also need to link to libgfortran.a.)
My liblapack.a and librefblas.a are not in a standard location, so I need to
cater for that, too. (This aspect is not generally an issue with
Strawberry.)

Ok, I guess the win32 and library dependence support
needs more than a little bit of work. I was hoping it was
something simple. Thanks for looking.

--Chris

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall

Post by Chris Marshall

Post by s***@optusnet.com.au
It's rather hard to write portable Makefiles.PL that handle this
automatically. What are the names of the lapack/blas libraries
against which to build this module on Strawberry ?
(Strawberry doesn't ship with these libraries - they need to
be built, or binaries obtained.)

Ok, I guess the win32 and library dependence support
needs more than a little bit of work. I was hoping it was
something simple. Thanks for looking.

I had awful trouble trying to find suitable lapack/blas library sources.
Then, out of the blue, John Lapeyre put me onto the lapack-3.4.2 source
available from
http://www.netlib.org/lapack/.

That library worked fine with both PDL::LinearAlgebra and PDL::FIT::Levmar.

I see the current version is 3.5.0, and it seems we might be able to now
build it using cmake (I used mingw32-make):

http://www.netlib.org/lapack/#_lapack_for_windows

There's also mention of pre-built binaries for Windows being available.

Cheers,
Rob

[Dima Kogan]

Post by s***@optusnet.com.au
-----Original Message-----
From: Chris Marshall

Post by Chris Marshall

Post by s***@optusnet.com.au
It's rather hard to write portable Makefiles.PL that handle this
automatically. What are the names of the lapack/blas libraries
against which to build this module on Strawberry ?
(Strawberry doesn't ship with these libraries - they need to
be built, or binaries obtained.)

Ok, I guess the win32 and library dependence support
needs more than a little bit of work. I was hoping it was
something simple. Thanks for looking.

I had awful trouble trying to find suitable lapack/blas library sources.
Then, out of the blue, John Lapeyre put me onto the lapack-3.4.2 source
available from
http://www.netlib.org/lapack/.

That's the reference (unoptimized) implementation of BLAS/LAPACK. You
almost certainly want an optimized library (ATLAS, MKL, etc). Many of
those are proprietary and closed source. But why do you want to compile
this, anyway?

dima

[Chris Marshall]

Post by Dima Kogan

Post by s***@optusnet.com.au
-----Original Message-----
From: Chris Marshall

Post by Chris Marshall

Post by s***@optusnet.com.au
It's rather hard to write portable Makefiles.PL that handle this
automatically. What are the names of the lapack/blas libraries
against which to build this module on Strawberry ?
(Strawberry doesn't ship with these libraries - they need to
be built, or binaries obtained.)

Ok, I guess the win32 and library dependence support
needs more than a little bit of work. I was hoping it was
something simple. Thanks for looking.

I had awful trouble trying to find suitable lapack/blas library sources.
Then, out of the blue, John Lapeyre put me onto the lapack-3.4.2 source
available from
http://www.netlib.org/lapack/.

That's the reference (unoptimized) implementation of BLAS/LAPACK. You
almost certainly want an optimized library (ATLAS, MKL, etc). Many of
those are proprietary and closed source. But why do you want to compile
this, anyway?

The goal is to have PDL (including PDL::LinearAlgebra) work on
windows platforms. Many folks are not aware of this fact, but there
is *no* standard package manager for windows. In many/most
cases, if you want something to run on a win32 perl, you need to
provide any needed dependencies. The same difficulty arises for
PDL::FFTW3 for the same reasons.

A general approach for a solution is the use of Alien packages to
wrap the dependency installation and make it available via CPAN.
Of course, it takes time to get that done.

--Chris

[Dima Kogan]

Post by Chris Marshall
The goal is to have PDL (including PDL::LinearAlgebra) work on
windows platforms. Many folks are not aware of this fact, but there
is *no* standard package manager for windows. In many/most
cases, if you want something to run on a win32 perl, you need to
provide any needed dependencies. The same difficulty arises for
PDL::FFTW3 for the same reasons.
A general approach for a solution is the use of Alien packages to
wrap the dependency installation and make it available via CPAN.
Of course, it takes time to get that done.

That's certainly all fine by me. But is the best solution really to
find, build and use a substandard implementation of BLAS? This is not a
rhetorical question, by the way. Maybe this IS the best solution on that
platform.

dima

[Chris Marshall]

Post by Dima Kogan

Post by Chris Marshall
The goal is to have PDL (including PDL::LinearAlgebra) work on
windows platforms. Many folks are not aware of this fact, but there
is *no* standard package manager for windows. In many/most
cases, if you want something to run on a win32 perl, you need to
provide any needed dependencies. The same difficulty arises for
PDL::FFTW3 for the same reasons.
A general approach for a solution is the use of Alien packages to
wrap the dependency installation and make it available via CPAN.
Of course, it takes time to get that done.

That's certainly all fine by me. But is the best solution really to
find, build and use a substandard implementation of BLAS? This is not a
rhetorical question, by the way. Maybe this IS the best solution on that
platform.

The Alien::BLAS or whatever could, presumably check for an existing
high[er] performance library. At the moment, the current library for
PDL::LinearAlgebra is non-existant so even a reference implementation
would be faster. Would you rather have no LAPACK/BLAS support
on your platform instead of a working but slower version?

In my experience, getting things to work correctly and consistently
across platform means users can get the job done and allows for
performance improvements down the line---especially if someone
knowledgeable with the library and other issues steps up to help. :-)

--Chris

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall

Post by Chris Marshall

Post by Dima Kogan
That's the reference (unoptimized) implementation of BLAS/LAPACK. You
almost certainly want an optimized library (ATLAS, MKL, etc). Many of
those are proprietary and closed source. But why do you want to compile
this, anyway?

I provide ppm packages of various perl extensions including PDL and a number
of PDL::* modules. (Full list is to be found at:
http://www.sisyphusion.tk/ppmindex.html )

It just makes these modules (which include PDL::LinearAlgebra) readily
available to anyone running ActivePerl or StrawberryPerl - without the need
for them to first build or locate any requisite libraries - and with no need
to concern themselves with Makefiles.PL that aren't appropriately
configured.

Wherever possible (and this is the case with PDL::LinearAlgebra), I build
against *static* libraries - so there's no need to distribute the library
itself, nor to worry that the packaged code might try to run against another
(different) instance of the library.
I *think* I can legally provide a ppm package built against most static
libraries (including perhaps even proprietary ones) without violating terms
of usage/distribution - because I'm not actually distributing the library
itself. (Anyone have views on that ?)

I don't personally use any of the PDL stuff myself - I don't engage in any
activities that call for it.
It's just there for anyone who might like to try to make use of it - and to
suggest improvements that could be made (as has happened from time to time).
If there's no opportunity to use it, then there's not much chance of it
being improved ;-)

Post by Chris Marshall
The same difficulty arises for
PDL::FFTW3 for the same reasons.

There's still those "Free to wrong pool errors" to solve as regards
PDL::FFTW3 and windows.

You may recall that we discussed them here a few weeks (months ?) ago.
They're a bit nasty - they happen in PDL itself; they happen well before the
final cleanup at the end of the script; and they haven't disappeared yet.

I did find a somewhat questionable method of avoiding them on 32-bit perls,
but could not find any hack at all that worked with 64-bit perls.
I'll try to get back to it soon ... and if I can get that done, we'll also
have ppm packages for PDL::FFTW3.

Cheers,
Rob

[Dima Kogan]

Post by s***@optusnet.com.au
-----Original Message-----
From: Chris Marshall

Post by Dima Kogan
That's the reference (unoptimized) implementation of BLAS/LAPACK. You
almost certainly want an optimized library (ATLAS, MKL, etc). Many of
those are proprietary and closed source. But why do you want to compile
this, anyway?

Wherever possible (and this is the case with PDL::LinearAlgebra), I build
against *static* libraries - so there's no need to distribute the library
itself, nor to worry that the packaged code might try to run against another
(different) instance of the library.
I *think* I can legally provide a ppm package built against most static
libraries (including perhaps even proprietary ones) without violating terms
of usage/distribution - because I'm not actually distributing the library
itself. (Anyone have views on that ?)

It depends on the licensing of the components. The most common issue to
watch out for is this: if any of the components are licensed under the
GPL, then the full thing must be licensed under the GPL also. If that is
impossible (because another component is proprietary for instance), then
you cannot legally distribute the full thing.