Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] package/python-numpy: fix occasional build failure with lapack
Date: Sun, 26 May 2019 13:43:23 +0200	[thread overview]
Message-ID: <87imtxl9us.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <d08e9569-ab62-3cd2-e1ab-64b5c8aa85b8@mind.be> (Arnout Vandecappelle's message of "Sun, 26 May 2019 11:43:47 +0200")

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >>> But IMHO we should proceed with dropping clapack.

 >  Why? it is maintained, and it is a dependency of armadillo...

 >  I had a deeper look, and actually lapack and clapack are the same, just
 > compiled differently: lapack is built with the fortran compiler, clapack is
 > generated with f2c (by upstream) and built with the C compiler. AFAIU, anything
 > that uses lapack should also be able to use clapack and vice versa.

 >  We have two packages like that: numpy and armadillo. They both seem to support
 > both lapack and clapack.

 >  So, it seems indeed removing clapack is the appropriate thing. Except: lapack
 > requires a fortran compiler, which is not always available. So in that sense, it
 > would actually be more appropriate to remove lapack...

 >  But maybe it would be better to normally use lapack, and only enable clapack
 > when lapack isn't available (i.e. when there's no fortran compiler).

Not knowing anything about (c)lapack (or fortran), is there any
performance advantage using lapack over clapack? Otherwise just always
using clapack seems like the simplest solution.

-- 
Bye, Peter Korsgaard

  parent reply	other threads:[~2019-05-26 11:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 14:41 [Buildroot] [PATCH] package/python-numpy: fix occasional build failure with lapack Giulio Benetti
2019-05-15 15:12 ` Yann E. MORIN
2019-05-15 19:58   ` Giulio Benetti
2019-05-15 20:50     ` Giulio Benetti
2019-05-15 21:03       ` [Buildroot] [PATCH v2] " Giulio Benetti
2019-05-18 20:13         ` Thomas Petazzoni
2019-05-19 14:47           ` Giulio Benetti
2019-05-20 17:48             ` Giulio Benetti
2019-05-20 17:49               ` Giulio Benetti
2019-05-26  9:43                 ` Arnout Vandecappelle
2019-05-26 10:11                   ` Giulio Benetti
2019-05-26 11:43                   ` Peter Korsgaard [this message]
2019-05-26 12:29                     ` Arnout Vandecappelle
2019-05-28  5:34                       ` Benjamin Kamath
2019-07-03 20:48                         ` Romain Naour
2019-05-28 14:57                       ` Bernd Kuhls

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=87imtxl9us.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@busybox.net \
    /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