From: Francois Bissey <fbissey@slingshot.co.nz>
To: gentoo-science@lists.gentoo.org
Subject: Re: [gentoo-science] BLAS and LAPACK dependecy resolution
Date: Sat, 14 Sep 2013 21:33:35 +1200 [thread overview]
Message-ID: <52342D6F.8030500@slingshot.co.nz> (raw)
In-Reply-To: <87wqmjhlaf.wl%oehme.markus@gmx.de>
On 14/09/13 20:14, Markus Oehme wrote:
> Hi,
>
> At Thu, 12 Sep 2013 11:19:11 +0200,
> Markus wrote:
>> 4. remove /usr/lib/libblas.so (which was kept by preserve-libs)
>> that is actually do 'rm /usr/lib/libblas.so'
>
>
> I see something really strange: repeatedly merging lapack-reference causes
> it to bounce between two states. Where in one state there are three
> additional files installed by the package:
> /usr/lib/debug/usr/lib64/libblas.so.debug
> /usr/lib64/libblas.so
> /usr/lib64/pkgconfig/blas.pc
> I tried it a larger number of times and the package alternates predictably
> between the two states. Any hints on how this can happen? Also it seems that
> in the state where the files are not there other packages have difficulties
> finding BLAS -- so the woes do not seem to be over yet. *sigh*
>
>
lapack-reference includes blas-reference. It looks to me that what
happens when you get these extra files is the following:
1) There is no blas properly eselected (or is broken)
2) because of (1) lapack-reference fails to find a blas at configure
time and therefore builds its own.
3) lapack-reference install libblas.so and related files.
At this stage in the cycle you merge lapack-reference again
1) while there is no blas properly eselected at configure stage the
previously installed libblas.so is found.
2) lapack-reference uses it to build libreflapack.so.
3) when lapack-reference is merged it doesn't include a libblas.so
and portage removes it when cleaning files from the previous merge.
Repeat....
So the solution is: properly eselect a blas and make sure it is a valid
and sane configuration.
I know this is annoying but after each time you merge a
blas/cblas/lapack and related friends which use altenatives, you need to
check
what is eselected.
Usually something valid is eselected but if you have several
implementations at the same time it tends to reset to the first one
in the list after each merge.
Francois
next prev parent reply other threads:[~2013-09-14 9:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 22:16 [gentoo-science] BLAS and LAPACK dependecy resolution Markus Oehme
2013-09-11 23:49 ` Horea Christian
2013-09-11 23:58 ` François Bissey
2013-09-12 0:26 ` François Bissey
2013-09-12 9:19 ` Markus Oehme
2013-09-12 9:39 ` Francois Bissey
2013-09-12 12:52 ` Markus Oehme
2013-09-13 0:22 ` François Bissey
2013-09-14 8:14 ` Markus Oehme
2013-09-14 9:33 ` Francois Bissey [this message]
2013-09-14 11:29 ` Markus Oehme
2013-09-26 22:43 ` Wiki stuff (was: [gentoo-science] BLAS and LAPACK dependecy resolution) Markus Oehme
2013-10-29 10:33 ` [gentoo-science] BLAS and LAPACK dependecy resolution Markus Oehme
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52342D6F.8030500@slingshot.co.nz \
--to=fbissey@slingshot.co.nz \
--cc=gentoo-science@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox