[Buildroot] [PATCH v2] package/python-numpy: fix occasional build failure with lapack

Romain Naour romain.naour at smile.fr
Wed Jul 3 20:48:53 UTC 2019


Hi Giulio, All,

Le 28/05/2019 à 07:34, Benjamin Kamath a écrit :
> Sub options ate my last reply. Re-posting to list.
> 
> On Sun, May 26, 2019 at 5:29 AM Arnout Vandecappelle <arnout at mind.be> wrote:
>>
>>
>>
>> On 26/05/2019 13:43, Peter Korsgaard wrote:
>>>>>>>> "Arnout" == Arnout Vandecappelle <arnout at 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...

Maybe we should convince Thomas to generate toolchains from toolchain-builder
project with gFortran :

http://patchwork.ozlabs.org/patch/1113806/

>>>
>>>  >  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.
>>
>>  Sounds OK to me.
>>
>>  Bernd, you're the only one who ever made a real contribution to lapack. Thoughts?
>>
>>  Benjamin, you originally contributed lapack. Any ideas?
> 
> I think lapack also might serve as a useful reference design for
> anyone trying to bring an external Fortran package into their build.
> 
> If one is much more difficult to maintain, it makes sense to get rid
> of that one. I think in this case clapack might be pretty well
> maintained, but in general it's nice to avoid intermediate sources as
> they are just another level of indirection where problems can occur.
> 
> Don't feel very strongly one way or the other. At this point, both
> will be in the history so breadcrumbs are there if someone wants to
> use the package that has support dropped.

Actually python-numpy doesn't seems to work at all due to a runtime issue:

http://patchwork.ozlabs.org/patch/1114198/

http://patchwork.ozlabs.org/patch/1112759/
(It would be great if python-numpy is runtime tested in gitlab)

Also, using uClibc fail too for another reason.

Sorry, I missed this thread while working on theses patches...

As a side project, I'm testing python-scipy package that require gFortran to
build. For now Python is stuck while importing the library for some reason...

Best regards,
Romain

> 
> Cheers,
> Ben
> 
>>
>>  Regards,
>>  Arnout
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 



More information about the buildroot mailing list