[Slackbuilds-users] Lapack SlackBuild
Serban Udrea
serban.udrea at skmail.ikp.physik.tu-darmstadt.de
Wed Jul 18 14:51:05 UTC 2012
On 07/18/2012 03:23 PM, James Smith wrote:
>> ... Moreover I definitely doubt that lapack should by any means provide
>> a blas function...
>
> It's not providing the blas function to users of the library, it's
> providing it to the library itself...
OK, got it.
>
> If lapack uses blas it must link against it, otherwise it can't call the
> code. I imagine these other applications are linking against blas
> themselves, which provides blas to lapack, whereas hmatrix isn't. But
> blas is a dependency of lapack, not of hmatrix, so that is correct in my
> opinion, although I don't know the conventions.
Indeed, any piece of software(*) I use, got linked both to lapack and
blas (in my case atlas). So from this point of view hmatrix is the only
one I heard about doing it differently.
(*) Which has something to do with lapack, e.g. scipy and umfpack.
> Like Eugene comments in his SlackBuild it really would be nice if lapack
> built the .so themselves :P All I had for reference was the Debian and
> Fedora packages and who knows if we should trust them.
Well, I'm also a Debian user, so I do think I trust them too.
>> BTW, did you consider using ATLAS instead of the reference blas?
>
> I did, but for what I'm using it for I'm not too interested in
> performance, and it seemed like a fair amount of effort :-) It might be
> worth it now to see if it exhibits the same problem.
>
Hmm, I thought I took something like 90% of the effort off, by providing
the SlackBuilds for atlas and lapack-atlas. Actually, the default
settings to these scripts should work for most use cases.
As with the problem, I would be surprised if it wouldn't be there,
since, as I wrote, I basically do the same as Eugene when building the
dynamic libraries.
Best regards,
Serban
More information about the SlackBuilds-users
mailing list