From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Korsgaard Date: Sun, 26 May 2019 13:43:23 +0200 Subject: [Buildroot] [PATCH v2] package/python-numpy: fix occasional build failure with lapack In-Reply-To: (Arnout Vandecappelle's message of "Sun, 26 May 2019 11:43:47 +0200") References: <20190515210342.126951-1-giulio.benetti@micronovasrl.com> <20190518221352.0630eaa6@windsurf> <74098714-11ae-9897-a5fb-71db0f04c44a@micronovasrl.com> Message-ID: <87imtxl9us.fsf@dell.be.48ers.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net >>>>> "Arnout" == Arnout Vandecappelle 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