2009/1/5 Jeff Spaleta <jspaleta@xxxxxxxxx>:
> On Sun, Jan 4, 2009 at 3:15 PM, Jonathan Underwood
> <jonathan.underwood@xxxxxxxxx> wrote:
>> Note also that building against lapack means that you package
>> installation may pull in atlas to satisfy the blas requirement of
>> lapack. Or it may pull in the blas package (a subpackage of lapack
>> which has a different blas implementation).
>
>
> This is the sort of thing that concerns me. But I can't reproduce the
> reported problem and that unnerves me even more. If this were a
> fragile dep resolution and linker logic interaction, that just
> happens to work in the default install situations.. i should be able
> to break it by doing weird things like forcing nodep package erases
> by hand and then asking yum to resolve deps. But I can't.
You can see what is happening if you do
export LD_DEBUG=libs
then run python and import scipy
On a system with only atlas installed (no lapack or blas):
[snip]
30261: find library=liblapack.so.3 [0]; searching
30261: search cache=/etc/ld.so.cache
30261: trying file=/usr/lib64/atlas/liblapack.so.3
[snip]
On installing the lapack package:
[snip]
30373: find library=liblapack.so.3 [0]; searching
30373: search cache=/etc/ld.so.cache
30373: trying file=/usr/lib64/atlas/liblapack.so.3
[snip]
Now installing blas and removing atlas does allow the "proper"
liblapack to be used:
[snip]
30408: find library=liblapack.so.3 [0]; searching
30408: search cache=/etc/ld.so.cache
30408: trying file=/usr/lib64/liblapack.so.3
[snip]
This is basically the situation as forced by the file
/etc/ld.so.conf.d/atlas-x86_64.conf which places the atlas libraries
at the front of the linker search path. It's a tough call as to
whether this is a useful default.
Personally I think that the liblapack provided by atlas should be renamed.
[Or liblapack should be set up using alternatives. Not sure if
alternatives works for libraries? Actually, what's really needed as
some sort of simple way for the user to select which library is used
when two or more have the same name.]
HTH,
J.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
