[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