| Message ID | 20190515210342.126951-1-giulio.benetti@micronovasrl.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] package/python-numpy: fix occasional buildfailure with lapack | expand |
Hello, On Wed, 15 May 2019 23:03:42 +0200 Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: > python-numpy build fails only if lapack is built before python-numpy > itself, and this doesn't always happen because lapack dependency is > missing in BR2_PYTHON_NUMPY_DEPENDENCIES. clapack is present > instead, but it's wrong since we're checking $(BR2_PACKAGE_LAPACK) not > $(BR2_PACKAGE_CLAPACK). I don't follow here: in the current code, we're checking BR2_PACKAGE_CLAPACK and adding clapack to PYTHON_NUMPY_DEPENDENCIES, which is consistent. In order to better understand the problem. Without this patch: - Does python-numpy builds fine when neither clapack nor lapack are enabled ? - Does python-numpy builds fine when clapack is enabled, but not lapack ? - What happens when both clapack and lapack are enabled ? Also, perhaps we need: select BR2_PACKAGE_LAPACK_COMPLEX if BR2_PACKAGE_LAPACK in the Config.in file, so that it's a bit easier for users: they don't have to know they need that specific sub-option of lapack. Best regards, Thomas
Hello Thomas, All, Il 18/05/2019 22:13, Thomas Petazzoni ha scritto: > Hello, > > On Wed, 15 May 2019 23:03:42 +0200 > Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: > >> python-numpy build fails only if lapack is built before python-numpy >> itself, and this doesn't always happen because lapack dependency is >> missing in BR2_PYTHON_NUMPY_DEPENDENCIES. clapack is present >> instead, but it's wrong since we're checking $(BR2_PACKAGE_LAPACK) not >> $(BR2_PACKAGE_CLAPACK). > > I don't follow here: in the current code, we're checking > BR2_PACKAGE_CLAPACK and adding clapack to PYTHON_NUMPY_DEPENDENCIES, > which is consistent. You're right, I've done a mistake, I've substituted clapack with lapack. So need to send a v3 with this corrected. The problem was due to cohexistence of lapack and clapack, but they are both(like openblas) accelerators that can exist once(I mean or lapack, or clapack). Here I was asking about inserting a menu to choose which accelerator to use: http://lists.busybox.net/pipermail/buildroot/2019-May/250273.html Can you take a look and answer with your opinion? > In order to better understand the problem. Without this patch: > > - Does python-numpy builds fine when neither clapack nor lapack are > enabled ? Yes it does(it works without accelerators). > - Does python-numpy builds fine when clapack is enabled, but not > lapack ? Yes > - What happens when both clapack and lapack are enabled ? Python-numpy will choose the accelerator according to this list: https://www.numpy.org/devdocs/user/building.html#accelerated-blas-lapack-libraries > Also, perhaps we need: > > select BR2_PACKAGE_LAPACK_COMPLEX if BR2_PACKAGE_LAPACK > > in the Config.in file, so that it's a bit easier for users: they don't > have to know they need that specific sub-option of lapack. If lapack selected yes, but that should come after adding a choice menu IMHO. Kind regards
Hello Thomas, Il 19/05/2019 16:47, Giulio Benetti ha scritto: > Hello Thomas, All, > > Il 18/05/2019 22:13, Thomas Petazzoni ha scritto: >> Hello, >> >> On Wed, 15 May 2019 23:03:42 +0200 >> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: >> >>> python-numpy build fails only if lapack is built before python-numpy >>> itself, and this doesn't always happen because lapack dependency is >>> missing in BR2_PYTHON_NUMPY_DEPENDENCIES. clapack is present >>> instead, but it's wrong since we're checking $(BR2_PACKAGE_LAPACK) not >>> $(BR2_PACKAGE_CLAPACK). >> >> I don't follow here: in the current code, we're checking >> BR2_PACKAGE_CLAPACK and adding clapack to PYTHON_NUMPY_DEPENDENCIES, >> which is consistent. > > You're right, I've done a mistake, I've substituted clapack with lapack. > So need to send a v3 with this corrected. > > The problem was due to cohexistence of lapack and clapack, but they are > both(like openblas) accelerators that can exist once(I mean or lapack, > or clapack). > Here I was asking about inserting a menu to choose which accelerator to > use: > http://lists.busybox.net/pipermail/buildroot/2019-May/250273.html > > Can you take a look and answer with your opinion? > >> In order to better understand the problem. Without this patch: >> >> - Does python-numpy builds fine when neither clapack nor lapack are >> enabled ? > > Yes it does(it works without accelerators). > >> - Does python-numpy builds fine when clapack is enabled, but not >> lapack ? > > Yes > >> - What happens when both clapack and lapack are enabled ? > > Python-numpy will choose the accelerator according to this list: > https://www.numpy.org/devdocs/user/building.html#accelerated-blas-lapack-libraries This ^^^^^^^^^^^^^ is wrong. The problem is that both lapack and clapack library names are equal: liblapack.so So what happens here is that python-numpy will use clapack headers, then it will link with liblapack.so causing linking error. Because liblapack.so is from lapack(not clapack) due to alphabetical order when building. Basically clapack is the c implementation of lapack, but in lapack it's been implemented lapacke(a c interface) that makes clapack useless at this point. I see 2 options: - remove clapack completely because it's the same as lapacke(embedded in lapack) - make clapack and lapack exclusive selectable in their Config.in like: (clapack Config.in) depends on !BR2_PACKAGE_LAPACK and: (lapack Config.in) depends on !BR2_PACKAGE_CLAPACK But IMHO we should proceed with dropping clapack. > >> Also, perhaps we need: >> >> select BR2_PACKAGE_LAPACK_COMPLEX if BR2_PACKAGE_LAPACK This ^^^^^^^^^^ instead never built succesfully. It built successfully only because I was trying to build with: make python-numpy-dirclean python-numpy instead of: make clean all So I had a mess of LAPACK libraries in my environment(sorry). Best regards-- Giulio Benetti CTO MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642 >> in the Config.in file, so that it's a bit easier for users: they don't >> have to know they need that specific sub-option of lapack. > > If lapack selected yes, but that should come after adding a choice menu > IMHO. > > Kind regards
Adding Samuel+, Il 20/05/2019 19:48, Giulio Benetti ha scritto: > Hello Thomas, > > Il 19/05/2019 16:47, Giulio Benetti ha scritto: >> Hello Thomas, All, >> >> Il 18/05/2019 22:13, Thomas Petazzoni ha scritto: >>> Hello, >>> >>> On Wed, 15 May 2019 23:03:42 +0200 >>> Giulio Benetti <giulio.benetti@micronovasrl.com> wrote: >>> >>>> python-numpy build fails only if lapack is built before python-numpy >>>> itself, and this doesn't always happen because lapack dependency is >>>> missing in BR2_PYTHON_NUMPY_DEPENDENCIES. clapack is present >>>> instead, but it's wrong since we're checking $(BR2_PACKAGE_LAPACK) not >>>> $(BR2_PACKAGE_CLAPACK). >>> >>> I don't follow here: in the current code, we're checking >>> BR2_PACKAGE_CLAPACK and adding clapack to PYTHON_NUMPY_DEPENDENCIES, >>> which is consistent. >> >> You're right, I've done a mistake, I've substituted clapack with lapack. >> So need to send a v3 with this corrected. >> >> The problem was due to cohexistence of lapack and clapack, but they >> are both(like openblas) accelerators that can exist once(I mean or >> lapack, or clapack). >> Here I was asking about inserting a menu to choose which accelerator >> to use: >> http://lists.busybox.net/pipermail/buildroot/2019-May/250273.html >> >> Can you take a look and answer with your opinion? >> >>> In order to better understand the problem. Without this patch: >>> >>> - Does python-numpy builds fine when neither clapack nor lapack are >>> enabled ? >> >> Yes it does(it works without accelerators). >> >>> - Does python-numpy builds fine when clapack is enabled, but not >>> lapack ? >> >> Yes >> >>> - What happens when both clapack and lapack are enabled ? >> >> Python-numpy will choose the accelerator according to this list: >> https://www.numpy.org/devdocs/user/building.html#accelerated-blas-lapack-libraries > > > This ^^^^^^^^^^^^^ is wrong. > The problem is that both lapack and clapack library names are equal: > liblapack.so > > So what happens here is that python-numpy will use clapack headers, > then it will link with liblapack.so causing linking error. > Because liblapack.so is from lapack(not clapack) due to alphabetical > order when building. > > Basically clapack is the c implementation of lapack, but in lapack it's > been implemented lapacke(a c interface) that makes clapack useless at > this point. > > I see 2 options: > - remove clapack completely because it's the same as lapacke(embedded in > lapack) > - make clapack and lapack exclusive selectable in their Config.in like: > (clapack Config.in) > depends on !BR2_PACKAGE_LAPACK > and: > (lapack Config.in) > depends on !BR2_PACKAGE_CLAPACK > > But IMHO we should proceed with dropping clapack. > >> >>> Also, perhaps we need: >>> >>> select BR2_PACKAGE_LAPACK_COMPLEX if BR2_PACKAGE_LAPACK > > This ^^^^^^^^^^ instead never built succesfully. > It built successfully only because I was trying to build with: > make python-numpy-dirclean python-numpy > instead of: > make clean all > > So I had a mess of LAPACK libraries in my environment(sorry). > > Best regards-- > Giulio Benetti > CTO > > MICRONOVA SRL > Sede: Via A. Niedda 3 - 35010 Vigonza (PD) > Tel. 049/8931563 - Fax 049/8931346 > Cod.Fiscale - P.IVA 02663420285 > Capitale Sociale € 26.000 i.v. > Iscritta al Reg. Imprese di Padova N. 02663420285 > Numero R.E.A. 258642 > >>> in the Config.in file, so that it's a bit easier for users: they don't >>> have to know they need that specific sub-option of lapack. >> >> If lapack selected yes, but that should come after adding a choice >> menu IMHO. >> >> Kind regards > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
On 20/05/2019 19:49, Giulio Benetti wrote: > Adding Samuel+, > > Il 20/05/2019 19:48, Giulio Benetti ha scritto: >> Hello Thomas, >> >> Il 19/05/2019 16:47, Giulio Benetti ha scritto: >>> Hello Thomas, All, >>> >>> Il 18/05/2019 22:13, Thomas Petazzoni ha scritto: [snip] >>>> - What happens when both clapack and lapack are enabled ? >>> >>> Python-numpy will choose the accelerator according to this list: >>> https://www.numpy.org/devdocs/user/building.html#accelerated-blas-lapack-libraries >> This ^^^^^^^^^^^^^ is wrong. >> The problem is that both lapack and clapack library names are equal: >> liblapack.so So, you are saying that if you build both lapack and clapack, you get only one .so file? >> So what happens here is that python-numpy will use clapack headers, >> then it will link with liblapack.so causing linking error. >> Because liblapack.so is from lapack(not clapack) due to alphabetical >> order when building. >> >> Basically clapack is the c implementation of lapack, but in lapack it's >> been implemented lapacke(a c interface) that makes clapack useless at >> this point. >> >> I see 2 options: >> - remove clapack completely because it's the same as lapacke(embedded in >> lapack) >> - make clapack and lapack exclusive selectable in their Config.in like: >> (clapack Config.in) >> depends on !BR2_PACKAGE_LAPACK >> and: >> (lapack Config.in) >> depends on !BR2_PACKAGE_CLAPACK We indeed have to make the mutually exclusive. There are a number of ways that we can do that. A. Add a dependency (not like above because it's a circular dependency). B. Turn it into a virtual package. C. Turn it into a choice (in addition to making it a virtual package). The latter is probably the proper way. Cfr. how it was done for openssl/libressl and libjpeg/turbo-jpeg. >> 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). Regards, Arnout >>>> Also, perhaps we need: >>>> >>>> select BR2_PACKAGE_LAPACK_COMPLEX if BR2_PACKAGE_LAPACK >> >> This ^^^^^^^^^^ instead never built succesfully. >> It built successfully only because I was trying to build with: >> make python-numpy-dirclean python-numpy >> instead of: >> make clean all >> >> So I had a mess of LAPACK libraries in my environment(sorry). >> >> Best regards-- >> Giulio Benetti >> CTO >> >> MICRONOVA SRL >> Sede: Via A. Niedda 3 - 35010 Vigonza (PD) >> Tel. 049/8931563 - Fax 049/8931346 >> Cod.Fiscale - P.IVA 02663420285 >> Capitale Sociale € 26.000 i.v. >> Iscritta al Reg. Imprese di Padova N. 02663420285 >> Numero R.E.A. 258642 >> >>>> in the Config.in file, so that it's a bit easier for users: they don't >>>> have to know they need that specific sub-option of lapack. >>> >>> If lapack selected yes, but that should come after adding a choice menu IMHO. >>> >>> Kind regards >> >> _______________________________________________ >> buildroot mailing list >> buildroot@busybox.net >> http://lists.busybox.net/mailman/listinfo/buildroot >
Hello Arnout, readding Samuel+, Il 26/05/2019 11:43, Arnout Vandecappelle ha scritto: > > > On 20/05/2019 19:49, Giulio Benetti wrote: >> Adding Samuel+, >> >> Il 20/05/2019 19:48, Giulio Benetti ha scritto: >>> Hello Thomas, >>> >>> Il 19/05/2019 16:47, Giulio Benetti ha scritto: >>>> Hello Thomas, All, >>>> >>>> Il 18/05/2019 22:13, Thomas Petazzoni ha scritto: > [snip] >>>>> - What happens when both clapack and lapack are enabled ? >>>> >>>> Python-numpy will choose the accelerator according to this list: >>>> https://www.numpy.org/devdocs/user/building.html#accelerated-blas-lapack-libraries >>> This ^^^^^^^^^^^^^ is wrong. >>> The problem is that both lapack and clapack library names are equal: >>> liblapack.so > > So, you are saying that if you build both lapack and clapack, you get only one > .so file? Exactly and lapack during install overwrite clapacks's liblapack.so with its liblapack.so > >>> So what happens here is that python-numpy will use clapack headers, >>> then it will link with liblapack.so causing linking error. >>> Because liblapack.so is from lapack(not clapack) due to alphabetical >>> order when building. >>> >>> Basically clapack is the c implementation of lapack, but in lapack it's >>> been implemented lapacke(a c interface) that makes clapack useless at >>> this point. >>> >>> I see 2 options: >>> - remove clapack completely because it's the same as lapacke(embedded in >>> lapack) >>> - make clapack and lapack exclusive selectable in their Config.in like: >>> (clapack Config.in) >>> depends on !BR2_PACKAGE_LAPACK >>> and: >>> (lapack Config.in) >>> depends on !BR2_PACKAGE_CLAPACK > > We indeed have to make the mutually exclusive. There are a number of ways that > we can do that. > > A. Add a dependency (not like above because it's a circular dependency). > > B. Turn it into a virtual package. > > C. Turn it into a choice (in addition to making it a virtual package). > > The latter is probably the proper way. Cfr. how it was done for > openssl/libressl and libjpeg/turbo-jpeg. I agree with using option C. Otherwise there will always be problems like this. > >>> 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. Yes, I thought about it too and this is why it makes more sense option C IMHO. > 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). Yes that can be done. But at this point I would make it with option C. Do I proceed that way? PS: I always try to add to CC Samuel and everytime it gets removed, is there a reason? Best regards
>>>>> "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.
On 26/05/2019 13:43, Peter Korsgaard wrote: >>>>>> "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. 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? Regards, Arnout
Sub options ate my last reply. Re-posting to list. On Sun, May 26, 2019 at 5:29 AM Arnout Vandecappelle <arnout@mind.be> wrote: > > > > On 26/05/2019 13:43, Peter Korsgaard wrote: > >>>>>> "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. > > 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. Cheers, Ben > > Regards, > Arnout
Am Sun, 26 May 2019 14:29:26 +0200 schrieb Arnout Vandecappelle: > Bernd, you're the only one who ever made a real contribution to lapack. > Thoughts? Hi Arnout, while it is true that I sent a version bump for lapack nearly two years ago this was part of a broader approach to bump many outdated packages. I never used lapack and therefore I am unable to contribute to the current discussion, sorry. Regards, Bernd
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@mind.be> wrote: >> >> >> >> On 26/05/2019 13:43, Peter Korsgaard wrote: >>>>>>>> "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... 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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
diff --git a/package/python-numpy/python-numpy.mk b/package/python-numpy/python-numpy.mk index 28dccf8be5..af210041a1 100644 --- a/package/python-numpy/python-numpy.mk +++ b/package/python-numpy/python-numpy.mk @@ -15,8 +15,8 @@ PYTHON_NUMPY_LICENSE_FILES = LICENSE.txt doc/sphinxext/LICENSE.txt \ numpy/core/src/multiarray/dragon4.c PYTHON_NUMPY_SETUP_TYPE = setuptools -ifeq ($(BR2_PACKAGE_CLAPACK),y) -PYTHON_NUMPY_DEPENDENCIES += clapack +ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y) +PYTHON_NUMPY_DEPENDENCIES += lapack PYTHON_NUMPY_SITE_CFG_LIBS += blas lapack else PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
python-numpy build fails only if lapack is built before python-numpy itself, and this doesn't always happen because lapack dependency is missing in BR2_PYTHON_NUMPY_DEPENDENCIES. clapack is present instead, but it's wrong since we're checking $(BR2_PACKAGE_LAPACK) not $(BR2_PACKAGE_CLAPACK). Once clapack is substituted with lapack build failure is due to missing BR2_PACKAGE_LAPACK_COMPLEX that provides some functions in lapack libraries needed by python-numpy. So: - substitute clapack with lapack in BR2_PYTHON_NUMPY_DEPENDENCIES when BR2_PACKAGE_LAPACK = y - substitute ifeq check "$(BR2_PACKAGE_LAPACK),y" with "$(BR2_PACKAGE_LAPACK_COMPLEX),y" because python-numpy needs COMPLEX functions and BR2_PACKAGE_LAPACK_COMPLEX inherits BR2_PACKAGE_LAPACK Fixes: http://autobuild.buildroot.net/results/50f/50f7f09a9f830cd7b94f8fc83c09fc3d39297d3d/ Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> --- package/python-numpy/python-numpy.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)