9.1.beta0 build failure on Arch

[Antonio Rojas]

Build fails at fflas-ffpack, log attached. Seems related to FS#27870

[Dima Pasechnik]

isn't it due to https://trac.sagemath.org/ticket/27444 - which removed
--disable-openmp from fflas-ffpack flags ?
see https://trac.sagemath.org/ticket/27444#comment:34

On Sat, Jan 11, 2020 at 7:53 AM Antonio Rojas <nqn...@gmail.com> wrote:
>
> Build fails at fflas-ffpack, log attached. Seems related to FS#27870
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9768e0af-b10a-4721-844c-6a81832a117b%40googlegroups.com.

[Antonio Rojas]

I don't think so - I'm pretty sure I've built it successfully after that commit. 

El sábado, 11 de enero de 2020, 9:25:04 (UTC+1), Dima Pasechnik escribió:

isn't it due to https://trac.sagemath.org/ticket/27444 - which removed
--disable-openmp from fflas-ffpack flags ?
see https://trac.sagemath.org/ticket/27444#comment:34

On Sat, Jan 11, 2020 at 7:53 AM Antonio Rojas <nqn...@gmail.com> wrote:
>
> Build fails at fflas-ffpack, log attached. Seems related to FS#27870
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.

[Dima Pasechnik]

On Sat, Jan 11, 2020 at 8:57 AM Antonio Rojas <nqn...@gmail.com> wrote:
>
> I don't think so - I'm pretty sure I've built it successfully after that commit.
>

please compare the system openblas linkage with the one you build in
Sage, and post the outputs of ldd here.
I am pretty sure there is an interesting
difference, I only don't know which way.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/488d598b-5232-4ee5-90ef-82b3ebd982fd%40googlegroups.com.

[Antonio Rojas]

openblas is not being built in Sage, the system one is detected and used after FS#27870. FWIW, building our distro fflas-ffpack package with our system openblas works fine.

El sábado, 11 de enero de 2020, 10:00:43 (UTC+1), Dima Pasechnik escribió:

On Sat, Jan 11, 2020 at 8:57 AM Antonio Rojas <nqn...@gmail.com> wrote:
>
> I don't think so - I'm pretty sure I've built it successfully after that commit.
>
please compare the system openblas linkage with the one you build in
Sage, and post the outputs of ldd here.
I am pretty sure there is an interesting
difference, I only don't know which way.


> El sábado, 11 de enero de 2020, 9:25:04 (UTC+1), Dima Pasechnik escribió:
>>
>> isn't it due to https://trac.sagemath.org/ticket/27444 - which removed
>> --disable-openmp from fflas-ffpack flags ?
>> see https://trac.sagemath.org/ticket/27444#comment:34
>>
>> On Sat, Jan 11, 2020 at 7:53 AM Antonio Rojas <nqn...@gmail.com> wrote:
>> >
>> > Build fails at fflas-ffpack, log attached. Seems related to FS#27870
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "sage-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.
>> > To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9768e0af-b10a-4721-844c-6a81832a117b%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/488d598b-5232-4ee5-90ef-82b3ebd982fd%40googlegroups.com.

[Dima Pasechnik]

On Sat, 11 Jan 2020, 09:21 Antonio Rojas, <nqn...@gmail.com> wrote:

openblas is not being built in Sage, the system one is detected and used after FS#27870. FWIW, building our distro fflas-ffpack package with our system openblas works fine.

the question is why on your system it causes a problem. this setup, with external openblas, has been tested on many different OS.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/16b2c949-712d-4c2e-9833-621da436cbb9%40googlegroups.com.

[arojas]

I suspect this may be due to our openblas package only providing libblas.so (not libcblas.so or liblapack.so, which in our case come from the netlib blas).

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/16b2c949-712d-4c2e-9833-621da436cbb9%40googlegroups.com.

[Dima Pasechnik]

On Sat, 11 Jan 2020, 10:19 arojas, <nqn...@gmail.com> wrote:

I suspect this may be due to our openblas package only providing libblas.so (not libcblas.so or liblapack.so, which in our case come from the netlib blas).

Are you saying that your libopenblas.so does not provide everything that is in openblas by default? 

This is largely defeating its purpose.

Sage's openblas does provide the cblas and lapack capabilities.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/159ed5d5-a263-41e7-89fa-da16e4450a40%40googlegroups.com.

[arojas]

El sábado, 11 de enero de 2020, 11:23:32 (UTC+1), Dima Pasechnik escribió:

On Sat, 11 Jan 2020, 10:19 arojas, <nqn...@gmail.com> wrote:

I suspect this may be due to our openblas package only providing libblas.so (not libcblas.so or liblapack.so, which in our case come from the netlib blas).

Are you saying that your libopenblas.so does not provide everything that is in openblas by default? 

This is largely defeating its purpose.

Sage's openblas does provide the cblas and lapack capabilities.

 In that case, openblas' spkg-configure should check whether cblas symbols are provided by the system openblas, and if not it should compile sage's one. It shouldn't unconditionally assume that that's always the case.

[Dima Pasechnik]

I maintain that it's a bug in Arch, that libopenblas cannot be used as
a replacement of cblas and lapack, for it defeats its purpose.
Most uses of BLAS routines are either via LAPACK, or from C/C++, via cblas.

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a1516e56-ab25-410e-be0f-75a7a6713466%40googlegroups.com.

[Vincent Delecroix]

I had the same annoying trouble... Is it really a bug in arch? I don't
find anywhere where libopenblas is supposed to provide the LAPACK
interface. To me it is just true for SageMath and false for Archlinux.

[Vincent Delecroix]

Moreover, SageMath does work on archlinux perfectly well when
installed from the package manager. Antonio, do you have some
tweaks to deal with the blas/lapack settings when compiling
for archlinux?

[Dima Pasechnik]

On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix

<20100.d...@gmail.com> wrote:
>
> I had the same annoying trouble... Is it really a bug in arch? I don't
> find anywhere where libopenblas is supposed to provide the LAPACK
> interface. To me it is just true for SageMath and false for Archlinux.

well, a "bug", in the sense that their openblas configuration just
does not make any sense,
because if you install a highly optimised BLAS implementation, which can also
provided a highly optimised CBLAS and LAPACK, in a sane world you'd install them
too. But Arch does not do this, it instead provides dog-slow CBLAS and
LAPACK, built
from another (reference, i.e. no assembler, no optimisation) implementation.
This causes Sage's logic, which expects that openblas will also
provide CBLAS and LAPACK, to fail.

Yes, it is possible to make tests to detect this silly setup, but I
think that everyone's time
is much better spent if Arch provided a full build of openblas, with
CBLAS and LAPACK,
instead.

>
> Le 13/01/2020 à 11:44, Dima Pasechnik a écrit :
> > On Sat, Jan 11, 2020 at 11:35 AM arojas <nqn...@gmail.com> wrote:
> >>
> >> El sábado, 11 de enero de 2020, 11:23:32 (UTC+1), Dima Pasechnik escribió:
> >>>
> >>>
> >>>
> >>> On Sat, 11 Jan 2020, 10:19 arojas, <nqn...@gmail.com> wrote:
> >>>>
> >>>> I suspect this may be due to our openblas package only providing libblas.so (not libcblas.so or liblapack.so, which in our case come from the netlib blas).
> >>>
> >>>
> >>> Are you saying that your libopenblas.so does not provide everything that is in openblas by default?
> >>>
> >>> This is largely defeating its purpose.
> >>> Sage's openblas does provide the cblas and lapack capabilities.
> >>
> >>
> >> In that case, openblas' spkg-configure should check whether cblas symbols are provided by the system openblas, and if not it should compile sage's one. It shouldn't unconditionally assume that that's always the case.
> >
> > I maintain that it's a bug in Arch, that libopenblas cannot be used as
> > a replacement of cblas and lapack, for it defeats its purpose.
> > Most uses of BLAS routines are either via LAPACK, or from C/C++, via cblas.
> >
> >
> >
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> >> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a1516e56-ab25-410e-be0f-75a7a6713466%40googlegroups.com.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/dbf38073-170b-4c7d-63b9-d4429a8794e2%40gmail.com.

[Vincent Delecroix]

Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
> On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
> <20100.d...@gmail.com> wrote:
>>
>> I had the same annoying trouble... Is it really a bug in arch? I don't
>> find anywhere where libopenblas is supposed to provide the LAPACK
>> interface. To me it is just true for SageMath and false for Archlinux.
>
> well, a "bug", in the sense that their openblas configuration just
> does not make any sense,
> because if you install a highly optimised BLAS implementation, which can also
> provided a highly optimised CBLAS and LAPACK, in a sane world you'd install them
> too. But Arch does not do this, it instead provides dog-slow CBLAS and
> LAPACK, built
> from another (reference, i.e. no assembler, no optimisation) implementation.
> This causes Sage's logic, which expects that openblas will also
> provide CBLAS and LAPACK, to fail.
>
> Yes, it is possible to make tests to detect this silly setup, but I
> think that everyone's time
> is much better spent if Arch provided a full build of openblas, with
> CBLAS and LAPACK,
> instead.

Hence there are two bugs

* a "logical" bug in archlinux that provides a slow lapack for
(apparently) no good reason

* a structural bug in SageMath that assumes that openblas does
install the LAPACK interface

I tend to agree that the resolution of any of these two would solve
the compilation. But in an ideal world we would just solve the two.

[Dima Pasechnik]

a meaningful resolution of this would be to test openblas for lapack and cblas capacities.

this is relatively easy, and would result in openblas on Arch being built by Sage.

as far as expanding this to other implementations of blas/lapack, 

it is harder.

>>
>> Le 13/01/2020 à 11:44, Dima Pasechnik a écrit :
>>> On Sat, Jan 11, 2020 at 11:35 AM arojas <nqn...@gmail.com> wrote:
>>>>
>>>> El sábado, 11 de enero de 2020, 11:23:32 (UTC+1), Dima Pasechnik escribió:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, 11 Jan 2020, 10:19 arojas, <nqn...@gmail.com> wrote:
>>>>>>
>>>>>> I suspect this may be due to our openblas package only providing libblas.so (not libcblas.so or liblapack.so, which in our case come from the netlib blas).
>>>>>
>>>>>
>>>>> Are you saying that your libopenblas.so does not provide everything that is in openblas by default?
>>>>>
>>>>> This is largely defeating its purpose.
>>>>> Sage's openblas does provide the cblas and lapack capabilities.
>>>>
>>>>
>>>>    In that case, openblas' spkg-configure should check whether cblas symbols are provided by the system openblas, and if not it should compile sage's one. It shouldn't unconditionally assume that that's always the case.
>>>
>>> I maintain that it's a bug in Arch, that libopenblas cannot be used as
>>> a replacement of cblas and lapack, for it defeats its purpose.
>>> Most uses of BLAS routines are either via LAPACK, or from C/C++, via cblas.
>>>
>>>
>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "sage-devel" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a1516e56-ab25-410e-be0f-75a7a6713466%40googlegroups.com.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/dbf38073-170b-4c7d-63b9-d4429a8794e2%40gmail.com.
>

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e3ad609d-8d21-bb10-2876-367fdf1b7e24%40gmail.com.

[Matthias Koeppe]

On Wednesday, January 22, 2020 at 10:27:02 AM UTC-5, Dima Pasechnik wrote:

a meaningful resolution of this would be to test openblas for lapack and cblas capacities.

this is relatively easy, and would result in openblas on Arch being built by Sage.

+1 on doing this.

 

[Isuru Fernando]

> But Arch does not do this, it instead provides dog-slow CBLAS and
LAPACK, built
from another (reference, i.e. no assembler, no optimisation) implementation.

This is simply not true. CBLAS's performance does not depend on which implementation it comes from. CBLAS's performance depends on the underlying BLAS implementation and on ArchLinux, when OpenBLAS is installed, CBLAS uses OpenBLAS as the underlying BLAS implementation. In fact, OpenBLAS uses the CBLAS code from Netlib's reference implementation.

As for LAPACK, in OpenBLAS, they have implemented a handful of functions to use OpenBLAS internals to make it parallel, but most of the LAPACK functions are from Netlib's Reference implementation. So, when ArchLinux is using LAPACK from netlib, they are losing out on only a few LAPACK functions.

Isuru

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3p7x9KmwHLmhjOtuoy_3PdsohHN6RJ0fp0Bzxv-wHODQ%40mail.gmail.com.

[Isuru Fernando]

There's also a 3rd bug which is in fflas-ffpack which assumes that if there's no cblas, then it's not openblas. This can be fixed by copying the lines https://github.com/linbox-team/fflas-ffpack/blob/2d3af1a5bec51983b5a896fae12e60914d9bdc4d/fflas-ffpack/config-blas.h#L315-L317 to Line 311 above the #else

Isuru

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e3ad609d-8d21-bb10-2876-367fdf1b7e24%40gmail.com.

[Dima Pasechnik]

On Wed, 22 Jan 2020, 15:59 Isuru Fernando, <isu...@gmail.com> wrote:

> But Arch does not do this, it instead provides dog-slow CBLAS and
LAPACK, built
from another (reference, i.e. no assembler, no optimisation) implementation.

This is simply not true. CBLAS's performance does not depend on which implementation it comes from. CBLAS's performance depends on the underlying BLAS implementation and on ArchLinux, when OpenBLAS is installed, CBLAS uses OpenBLAS as the underlying BLAS implementation. In fact, OpenBLAS uses the CBLAS code from Netlib's reference implementation.

errors we see here, regarding absence of certain openmp functions in cblas, seem to indicate that cblas on Arch does not come from openblas. perhaps what we see are reference cblas and blas from openblas installed at the same time, in error.

maybe they split openblas.so into separate sections for an unclear to me reason, but most applications I know uses cblas, blas and lapack, so they need to link them all anyway.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voO3C4pdc5gbU02KzhR1DuzZ0Gwv2n6CoSukODeEqFfEjQ%40mail.gmail.com.

[Isuru Fernando]

> errors we see here, regarding absence of certain openmp functions in cblas, seem to indicate that cblas on Arch does not come from openblas. perhaps what we see are reference cblas and blas from openblas installed at the same time, in error.

Can you please explain more? As I said earlier, it doesn't matter where CBLAS is coming from. I checked in Arch linux and cblas is linked to openblas.

[root@50586643ff22 /]# ldd /usr/lib/libcblas.so.3
        linux-vdso.so.1 (0x00007ffd2f7bb000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f848f079000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f848eeb2000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f848ed6c000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f848ed4a000)
        libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f848ed11000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007f84902dc000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f848ed0c000)

[root@50586643ff22 /]# ls -al /usr/lib/libblas.so.3
lrwxrwxrwx 1 root root 22 Aug 20 10:35 /usr/lib/libblas.so.3 -> libopenblasp-r0.3.7.so

Isuru

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1qxH7SUEWy%2BP3CQ_WeCimK_ByX3Q_HNz4Li%2BvwZCznYA%40mail.gmail.com.

[Isuru Fernando]

> maybe they split openblas.so into separate sections for an unclear to me reason, but most applications I know uses cblas, blas and lapack, so they need to link them all anyway.

True, but in sage you are copying `openblas.pc` to `cblas.pc` and `lapack.pc` which is wrong. `openblas.pc` should only be expected to provide blas.

A solution would be to check that `blas.pc`, `cblas.pc`, `lapack.pc` are already on the system and if not copy `openblas.pc` to the three names.

Isuru

[Dima Pasechnik]

On Wed, Jan 22, 2020 at 4:17 PM Isuru Fernando <isu...@gmail.com> wrote:
>
> > maybe they split openblas.so into separate sections for an unclear to me reason, but most applications I know uses cblas, blas and lapack, so they need to link them all anyway.
>
> True, but in sage you are copying `openblas.pc` to `cblas.pc` and `lapack.pc` which is wrong. `openblas.pc` should only be expected to provide blas.

this is system-dependent. Debian and Fedora have no libcblas and no
cblas.pc, cblas is provided by openblas.
Some *BSD systems have libcblas conflcting with libopenblas.

On Arch, does cblas.pc exist?

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voO-GZJ9gSgsQ-N4stwfkvonWz2aDU%2Bcpv6ViJ8eN%3D0wNw%40mail.gmail.com.

[Isuru Fernando]

> On Arch, does cblas.pc exist?

Yes.

> this is system-dependent.

Yes, that's why we need to have fallbacks.

Isuru

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3D4YGM2HR7SORfjDFhkjQ%3Dm1Jn4CsEwmioF-18poxRdQ%40mail.gmail.com.

[Dima Pasechnik]

On Wed, Jan 22, 2020 at 5:03 PM Isuru Fernando <isu...@gmail.com> wrote:
>
> > On Arch, does cblas.pc exist?
>
> Yes.

Thanks. I wonder what on Arch is the output of

pkg-config --modversion X

for X in [cblas,blas,lapack,openblas]

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voO%2BWkpafvpuUfLmGw8qDZ1qFMwzoA6HFBBBiZWYGdTqpw%40mail.gmail.com.

[Isuru Fernando]

[root@50586643ff22 /]# pkg-config --modversion blas
0.3.7
[root@50586643ff22 /]# pkg-config --modversion cblas
3.9.0
[root@50586643ff22 /]# pkg-config --modversion lapack
3.9.0
[root@50586643ff22 /]# pkg-config --modversion openblas
0.3.7

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1H_8RGBSN5DW25%3Dvf7SE_TJXeFtVpKSQQU%2BRcsDmFQ5w%40mail.gmail.com.

[Dima Pasechnik]

On Wed, Jan 22, 2020 at 5:20 PM Isuru Fernando <isu...@gmail.com> wrote:
>
> [root@50586643ff22 /]# pkg-config --modversion blas
> 0.3.7
> [root@50586643ff22 /]# pkg-config --modversion cblas
> 3.9.0
> [root@50586643ff22 /]# pkg-config --modversion lapack
> 3.9.0
> [root@50586643ff22 /]# pkg-config --modversion openblas
> 0.3.7

To make it robust, I'd only allow cblas.pc to be used if it really is
based on openblas
and the same for lapack.pc

One way to do this is to test openblas for a symbol that is on Arch
in cblas, not in openblas,
and the same for lapack.

Could someone figure out these symbols, or give me access to an Arch box?

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voMM5COObh5FWUd%2BH%2BXEweA_jbCrNdMCRvU3x6KhaYHsxQ%40mail.gmail.com.

[Dima Pasechnik]

On Thu, Jan 23, 2020 at 5:11 PM Dima Pasechnik <dim...@gmail.com> wrote:
>
> On Wed, Jan 22, 2020 at 5:20 PM Isuru Fernando <isu...@gmail.com> wrote:
> >
> > [root@50586643ff22 /]# pkg-config --modversion blas
> > 0.3.7
> > [root@50586643ff22 /]# pkg-config --modversion cblas
> > 3.9.0
> > [root@50586643ff22 /]# pkg-config --modversion lapack
> > 3.9.0
> > [root@50586643ff22 /]# pkg-config --modversion openblas
> > 0.3.7
>
> To make it robust, I'd only allow cblas.pc to be used if it really is
> based on openblas
> and the same for lapack.pc
>
> One way to do this is to test openblas for a symbol that is on Arch
> in cblas, not in openblas,
> and the same for lapack.
>
> Could someone figure out these symbols, or give me access to an Arch box?

I've opened https://trac.sagemath.org/ticket/29071 to deal with this issue.

[Isuru Fernando]

> One way to do this is to  test openblas for a symbol that is on Arch
in cblas, not in openblas,

I'm not sure I understand. Are you asking for a symbol in libcblas.so that is not in an libopenblas.so compiled with CBLAS?

> Could someone figure out these symbols, or give me access to an Arch box?

Sorry, I'm using docker for this.

Isuru

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq2%2BD6SLY1g1Q45K7yiq9H4h5Z%2BKM9cHV6c_2Qirupte%2Bw%40mail.gmail.com.

[Antonio Rojas]

El jueves, 23 de enero de 2020, 18:11:51 (UTC+1), Dima Pasechnik escribió:

On Wed, Jan 22, 2020 at 5:20 PM Isuru Fernando <isu...@gmail.com> wrote:
>
> [root@50586643ff22 /]# pkg-config --modversion blas
> 0.3.7
> [root@50586643ff22 /]# pkg-config --modversion cblas
> 3.9.0
> [root@50586643ff22 /]# pkg-config --modversion lapack
> 3.9.0
> [root@50586643ff22 /]# pkg-config --modversion openblas
> 0.3.7

To make it robust, I'd only allow cblas.pc to be used if it really is
based on openblas
and the same for lapack.pc

One way to do this is to  test openblas for a symbol that is on Arch
in cblas, not in openblas,
and the same for lapack.

Could someone figure out these symbols, or give me access to an Arch box?

fflas-fflack configure tests need cblas_dgemm, so you should check for that function.

 

[Dima Pasechnik]

Thanks, but how about lapack? What is a symbol in liblapack to check for?

>
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9958bcce-b800-4e45-b726-a553f2459429%40googlegroups.com.

[Isuru Fernando]

It depends on the fortran name mangling. For gfortran, one symbol would be dgeqrf_.

Isuru

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1OgMYiVfNmbCtVu%2BtokJCsF8LOs9L2dNH404SU1RGWXg%40mail.gmail.com.

[Dima Pasechnik]

Hi Antonio,
can Arch's Flint be fixed so that it links against NTL, like in Sage?
Then we won't have to build Flint (and Arb) on Arch...

On Sat, Jan 11, 2020 at 3:53 PM Antonio Rojas <nqn...@gmail.com> wrote:
>
> Build fails at fflas-ffpack, log attached. Seems related to FS#27870
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9768e0af-b10a-4721-844c-6a81832a117b%40googlegroups.com.

[Antonio Rojas]

I'm missing some context here... flint does certainly link to ntl already, i don't see how it could work otherwise.

[Dima Pasechnik]

On Tue, Apr 14, 2020 at 9:28 PM Antonio Rojas <nqn...@gmail.com> wrote:
>
> I'm missing some context here... flint does certainly link to ntl already, i don't see how it could work otherwise.

David just posted a message here claiming this not to be the case on
his Arch installation.
Perhaps he has an odd version of Flint conflicting with the system one?
(or just an old installation?)

>
>
> El martes, 14 de abril de 2020, 15:23:08 (UTC+2), Dima Pasechnik escribió:
>>
>> Hi Antonio,
>> can Arch's Flint be fixed so that it links against NTL, like in Sage?
>> Then we won't have to build Flint (and Arb) on Arch...
>>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/7ef8be6f-9bfd-4ac2-9186-949000571265%40googlegroups.com.

[Antonio Rojas]

That's osx, not Arch

El martes, 14 de abril de 2020, 15:38:27 (UTC+2), Dima Pasechnik escribió:

On Tue, Apr 14, 2020 at 9:28 PM Antonio Rojas <nqn...@gmail.com> wrote:
>
> I'm missing some context here... flint does certainly link to ntl already, i don't see how it could work otherwise.

David just posted a message here claiming this not to be the case on
his Arch installation.
Perhaps he has an odd version of Flint conflicting with the system one?
(or just an old installation?)

>
>
> El martes, 14 de abril de 2020, 15:23:08 (UTC+2), Dima Pasechnik escribió:
>>
>> Hi Antonio,
>> can Arch's Flint be fixed so that it links against NTL, like in Sage?
>> Then we won't have to build Flint (and Arb) on Arch...
>>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.

[Dima Pasechnik]

On Tue, Apr 14, 2020 at 9:47 PM Antonio Rojas <nqn...@gmail.com> wrote:
>
> That's osx, not Arch

oops, sorry for noise.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/8704ea8c-986e-442e-8563-ca40dc243d84%40googlegroups.com.