[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,


More information about the SlackBuilds-users mailing list