Atlas and lapack provide the same library..compiled differently... is that a problem?

[Jonathan Underwood]

2009/1/4 Jeff Spaleta <jspaleta at gmail.com>:
> On Sun, Jan 4, 2009 at 1:53 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> But this is in no way a complete regression test.
>
>
> I'm quite frankly not as competent as I would like to be with regard
> to runtime linker logic.
> So the issue may not be as dire as it could be...if the affected
> system in the bugreport is suffering due to local linker logic
> reconfiguration. Jury is out on that.
>
> But I do think its somewhat problematic in our packaging that lapack
> and atlas expose the same provides.
> F10: repoquery --whatprovides liblapack.so.3
> atlas-0:3.6.0-15.fc10.i386
> atlas-3dnow-0:3.6.0-15.fc10.i386
> atlas-sse-0:3.6.0-15.fc10.i386
> atlas-sse2-0:3.6.0-15.fc10.i386
> lapack-0:3.1.1-4.fc10.i386
>

FWIW the same situation is true for libblas:

$ repoquery --whatprovides libblas.so.3
atlas-sse-0:3.6.0-15.fc10.i386
atlas-3dnow-0:3.6.0-15.fc10.i386
blas-0:3.1.1-4.fc10.i386
atlas-sse2-0:3.6.0-15.fc10.i386
atlas-0:3.6.0-15.fc10.i386

(where blas is a subpackage of lapack).

Fortunately the blas interface is defined and so these should be abi
compatible. A knowledgeable user writing her own programs would ensure
that the atlas subdirectory is seen first by the linker when she wants
the optimised libraries, I suppose.