Arch Linux

I take it the binary package in the repo is not affected?

Please also follow this up with upstream, there is a contact adress on their website.

1. This is a bug in the source, so the binary package is affected. However, most likely this is a triviality:

real::sx(1)
...
if ((.false.).and.(sx(2)>0)) then
...
end if

So, potentially dangerous directives inside the if..endif will not be evaluated, but the compiler still computes the condition in (...), and execution may give segfault, because sx(2) is undefined. However, this is only a result of a quick glance at the file.

2. Done, please see the attached email.

PS: Also, I apologize for the inaccuracy in the title -- BLAS doesn't have SVD: s(d)rotm.f is an auxillary rotation subroutine. Please change if you feel necessary, because I can't edit the original post.

OK, my complaint was rather uneducated.

The BLAS, which we package (www.netlib.org/blas) indeed has multiple bugs (as can be demonstrated by the attached trivial testcase). However, these are fixed in the version, shipped with lapack. So, I suggest to merge the two packages into one PKGBUILD (attached below).

PS: I also don't understand the relevance of blas-link.patch... is it to make only gfortran ... -llapack and not -lblas -llapack?

the patch was to link dynamically against blas, suppose it is not needed if we use the one inside the lapack package.

It may be me, but I find it rather strange that they still have the blas package up on their homepage but in fact merged it with the lapack package (or I may have missed the note on their website). Either way, I'll switch the package over.

If I'm not mistaken one would need both lapack and blas for most usecases, so there is no need to split both packages from the lapack source (at least all official packages depend on both) ?

Well, lapack depends on blas, but nothing depends on lapack.

They don't include blas in the lapack package, but rather provide an option to build it via make blaslib. I just ran diff and saw that the invalid array declarations were corrected in lapack's blas source.

>It may be me, but I find it rather strange that they still have the blas package up on their homepage but in fact merged it with the >lapack package (or I may have missed the note on their website). Either way, I'll switch the package over.

Thanks, but can you wait for a little, while they get back to me over email, since I am going to ask them this question? I'll post here when it happens.

>the patch was to link dynamically against blas, suppose it is not needed if we use the one inside the lapack package.

My understanding (and this is also the authors' recommendation) is that it is better to use third-party BLAS, which is supposedly more optimized than the netlib's (or lapack's) one. While in practice it may not matter, I still think that the right way to link is -llapack -lmyblas, and not only -llapack.

This also means that if there is one package for both, people who use their own blas will end up with two blas libs...

sure, just ping me with the preferred solution when you have all the information you need.

Ronald, sorry for a delay.

I got the reply from lapack/blas devs. They acknowledge that there is a problem with netlib's blas, which was corrected in lapack's one. They also say that the blas at netlib will probably be upgraded soon, but I don't know when...

Regarding packaging, I think the decision should be based on your convenience (maintanence, etc.). In my opinion, people who really need these packages (on an Arch cluster, for instance) must compile their own libs [otherwise they will get what they deserve :)], while those who use Arch in a development environment (myself included) don't care much about performance and probably just need everything in one package for simplicity. That's my motivation for merging the two packages...