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

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

[Giulio Benetti]

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.
Then build failure is due to missing BR2_PACKAGE_LAPACK_COMPLEX that
provides some functions in lapack libraries needed by python-numpy.

So:
- add lapack to 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(-)

diff --git a/package/python-numpy/python-numpy.mk b/package/python-numpy/python-numpy.mk
index 28dccf8be5..a61246615a 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 += clapack lapack
 PYTHON_NUMPY_SITE_CFG_LIBS += blas lapack
 else
 PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
-- 
2.17.1

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

[Yann E. MORIN]

Giulio, All,

On 2019-05-15 16:41 +0200, Giulio Benetti spake thusly:
> 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.
> Then build failure is due to missing BR2_PACKAGE_LAPACK_COMPLEX that
> provides some functions in lapack libraries needed by python-numpy.
> 
> So:
> - add lapack to 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(-)
> 
> diff --git a/package/python-numpy/python-numpy.mk b/package/python-numpy/python-numpy.mk
> index 28dccf8be5..a61246615a 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 += clapack lapack

This is not correct, because tehre is no relation between lapack and
clapack. So, we can have lapack enabled but not clapack. Your code will
cause a build failure when clapack is not enabled.

So, you probably want something like:

    ifeq ($(BR2_PACKAGE_CLAPACK),y)
    PYTHON_NUMPY_DEPENDENCIES_LAPACK += clapack
    endif
    ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y)
    PYTHON_NUMPY_DEPENDENCIES_LAPACK += lapack
    endif
    ifneq ($(PYTHON_NUMPY_DEPENDENCIES_LAPACK),)
    PYTHON_NUMPY_DEPENDENCIES += $(PYTHON_NUMPY_DEPENDENCIES_LAPACK)
    else
    PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
    endif

But beware of the above, it might not yet be correct: if clapack and
lapack (without complex) are both enabled, then you may still en up in
the current situation.

So, you may need to refine it even further, with something like:

    ifeq ($(BR2_PACKAGE_CLAPACK),y)
    PYTHON_NUMPY_DEPENDENCIES += clapack
    PYTHON_NUMPY_ENV += BLAS=clapack LAPACK=clapack
    else ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y)
    PYTHON_NUMPY_DEPENDENCIES += lapack
    PYTHON_NUMPY_ENV += BLAS=lapack LAPACK=lapack
    else
    PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
    endif

(check what BLAS= and LAPACK= expect as values.)

Also, is the depenency on clapack really needed? Can python-numpy really
use clapack?

Regards,
Yann E. MORIN.

>  PYTHON_NUMPY_SITE_CFG_LIBS += blas lapack
>  else
>  PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
> -- 
> 2.17.1
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

[Giulio Benetti]

Hello Yann,

Il 15/05/2019 17:12, Yann E. MORIN ha scritto:
> Giulio, All,
> 
> On 2019-05-15 16:41 +0200, Giulio Benetti spake thusly:
>> 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.
>> Then build failure is due to missing BR2_PACKAGE_LAPACK_COMPLEX that
>> provides some functions in lapack libraries needed by python-numpy.
>>
>> So:
>> - add lapack to 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(-)
>>
>> diff --git a/package/python-numpy/python-numpy.mk b/package/python-numpy/python-numpy.mk
>> index 28dccf8be5..a61246615a 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 += clapack lapack
> 
> This is not correct, because tehre is no relation between lapack and
> clapack. So, we can have lapack enabled but not clapack. Your code will
> cause a build failure when clapack is not enabled.

Right, they should be exclusive.

> So, you probably want something like:
> 
>      ifeq ($(BR2_PACKAGE_CLAPACK),y)
>      PYTHON_NUMPY_DEPENDENCIES_LAPACK += clapack
>      endif
>      ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y)
>      PYTHON_NUMPY_DEPENDENCIES_LAPACK += lapack
>      endif
>      ifneq ($(PYTHON_NUMPY_DEPENDENCIES_LAPACK),)
>      PYTHON_NUMPY_DEPENDENCIES += $(PYTHON_NUMPY_DEPENDENCIES_LAPACK)
>      else
>      PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
>      endif
> 
> But beware of the above, it might not yet be correct: if clapack and
> lapack (without complex) are both enabled, then you may still en up in
> the current situation.

Right.

> So, you may need to refine it even further, with something like:
> 
>      ifeq ($(BR2_PACKAGE_CLAPACK),y)
>      PYTHON_NUMPY_DEPENDENCIES += clapack
>      PYTHON_NUMPY_ENV += BLAS=clapack LAPACK=clapack
>      else ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y)
>      PYTHON_NUMPY_DEPENDENCIES += lapack
>      PYTHON_NUMPY_ENV += BLAS=lapack LAPACK=lapack
>      else
>      PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
>      endif
> 
> (check what BLAS= and LAPACK= expect as values.)
> 
> Also, is the depenency on clapack really needed? Can python-numpy really
> use clapack?

Judging from here:
https://www.numpy.org/devdocs/user/building.html#blas
clapack seems to not be supported.
But AIK clapack should be the same as lapack but written entirely in C 
instead of Fortran(later translated in C in lapack during build), so it 
should work with clapack too.
I try to build with that and check.

Thanks for reviewing and proposing alternatives.

Kind 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

> Regards,
> Yann E. MORIN.
> 
>>   PYTHON_NUMPY_SITE_CFG_LIBS += blas lapack
>>   else
>>   PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
>> -- 
>> 2.17.1
>>
> 

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

[Giulio Benetti]

Il 15/05/2019 21:58, Giulio Benetti ha scritto:
> Hello Yann,
> 
> Il 15/05/2019 17:12, Yann E. MORIN ha scritto:
>> Giulio, All,
>>
>> On 2019-05-15 16:41 +0200, Giulio Benetti spake thusly:
>>> 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.
>>> Then build failure is due to missing BR2_PACKAGE_LAPACK_COMPLEX that
>>> provides some functions in lapack libraries needed by python-numpy.
>>>
>>> So:
>>> - add lapack to 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(-)
>>>
>>> diff --git a/package/python-numpy/python-numpy.mk b/package/python-numpy/python-numpy.mk
>>> index 28dccf8be5..a61246615a 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 += clapack lapack
>>
>> This is not correct, because tehre is no relation between lapack and
>> clapack. So, we can have lapack enabled but not clapack. Your code will
>> cause a build failure when clapack is not enabled.
> 
> Right, they should be exclusive.
> 
>> So, you probably want something like:
>>
>>       ifeq ($(BR2_PACKAGE_CLAPACK),y)
>>       PYTHON_NUMPY_DEPENDENCIES_LAPACK += clapack
>>       endif
>>       ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y)
>>       PYTHON_NUMPY_DEPENDENCIES_LAPACK += lapack
>>       endif
>>       ifneq ($(PYTHON_NUMPY_DEPENDENCIES_LAPACK),)
>>       PYTHON_NUMPY_DEPENDENCIES += $(PYTHON_NUMPY_DEPENDENCIES_LAPACK)
>>       else
>>       PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
>>       endif
>>
>> But beware of the above, it might not yet be correct: if clapack and
>> lapack (without complex) are both enabled, then you may still en up in
>> the current situation.
> 
> Right.
> 
>> So, you may need to refine it even further, with something like:
>>
>>       ifeq ($(BR2_PACKAGE_CLAPACK),y)
>>       PYTHON_NUMPY_DEPENDENCIES += clapack
>>       PYTHON_NUMPY_ENV += BLAS=clapack LAPACK=clapack
>>       else ifeq ($(BR2_PACKAGE_LAPACK_COMPLEX),y)
>>       PYTHON_NUMPY_DEPENDENCIES += lapack
>>       PYTHON_NUMPY_ENV += BLAS=lapack LAPACK=lapack
>>       else
>>       PYTHON_NUMPY_ENV += BLAS=None LAPACK=None
>>       endif
>>
>> (check what BLAS= and LAPACK= expect as values.)
>>
>> Also, is the depenency on clapack really needed? Can python-numpy really
>> use clapack?
> 
> Judging from here:
> https://www.numpy.org/devdocs/user/building.html#blas
> clapack seems to not be supported.
> But AIK clapack should be the same as lapack but written entirely in C
> instead of Fortran(later translated in C in lapack during build), so it
> should work with clapack too.
> I try to build with that and check.

I've successfully built python-numpy with these accelerators:
- lapack
- clapack(c verion of lapack(fortran))
- openblas

Speaking in IRC with Yann came out the possibility to specify LAPACK 
order with NPY_LAPACK_ORDER.

Another thing that could be done(after fixing current patch) is to add 
the choice in Config.in of which accelerator to use between these:
- lapack
- clapack
- openblas

IMHO I would like to impose LAPACK and BLAS instead of setting 
NPY_LAPACK_ORDER and NPY_BLAS_ORDER, since Buildroot is meant to be 
kinda "static" after building.

So I would:
- send a V2 patch to fix build failure using lapack only
then:
- follow with a second patch adding such choice

What about this?

Kind 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

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

[Giulio Benetti]

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(-)

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
-- 
2.17.1

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Giulio Benetti]

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
-- 
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

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

[Giulio Benetti]

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] [PATCH v2] package/python-numpy: fix occasional build failure with lapack

[Giulio Benetti]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
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

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

[Arnout Vandecappelle]

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 at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
> 

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

[Giulio Benetti]

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
-- 
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


>   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 at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot
>>

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

[Peter Korsgaard]

>>>>> "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

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

[Arnout Vandecappelle]

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

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

[Benjamin Kamath]

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

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

[Bernd Kuhls]

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

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

[Romain Naour]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>