9.1.beta0 build failure on Arch

121 views
Skip to first unread message

Antonio Rojas

unread,
Jan 11, 2020, 2:53:07 AM1/11/20
to sage-devel
Build fails at fflas-ffpack, log attached. Seems related to FS#27870
fflas_ffpack-2.4.3.log

Dima Pasechnik

unread,
Jan 11, 2020, 3:25:04 AM1/11/20
to sage-devel
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

unread,
Jan 11, 2020, 3:57:31 AM1/11/20
to sage-devel
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

unread,
Jan 11, 2020, 4:00:43 AM1/11/20
to sage-devel
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

unread,
Jan 11, 2020, 4:21:38 AM1/11/20
to sage-devel
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.

Dima Pasechnik

unread,
Jan 11, 2020, 4:38:07 AM1/11/20
to sage-devel


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

unread,
Jan 11, 2020, 5:19:10 AM1/11/20
to sage-devel
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).

Dima Pasechnik

unread,
Jan 11, 2020, 5:23:32 AM1/11/20
to sage-devel


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

unread,
Jan 11, 2020, 6:35:20 AM1/11/20
to sage-devel
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

unread,
Jan 13, 2020, 5:45:01 AM1/13/20
to sage-devel
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

unread,
Jan 22, 2020, 9:31:36 AM1/22/20
to sage-...@googlegroups.com
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

unread,
Jan 22, 2020, 9:33:04 AM1/22/20
to sage-...@googlegroups.com
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

unread,
Jan 22, 2020, 9:42:08 AM1/22/20
to sage-devel
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

unread,
Jan 22, 2020, 10:13:00 AM1/22/20
to sage-...@googlegroups.com
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

unread,
Jan 22, 2020, 10:27:02 AM1/22/20
to sage-devel
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.

Matthias Koeppe

unread,
Jan 22, 2020, 10:53:01 AM1/22/20
to sage-devel
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

unread,
Jan 22, 2020, 10:59:29 AM1/22/20
to sage-devel
> 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

Isuru Fernando

unread,
Jan 22, 2020, 11:06:07 AM1/22/20
to sage-devel
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

Dima Pasechnik

unread,
Jan 22, 2020, 11:09:02 AM1/22/20
to sage-devel


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.


Isuru Fernando

unread,
Jan 22, 2020, 11:14:50 AM1/22/20
to sage-devel
> 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

Isuru Fernando

unread,
Jan 22, 2020, 11:18:00 AM1/22/20
to sage-devel
> 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

unread,
Jan 22, 2020, 12:00:43 PM1/22/20
to sage-devel
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

unread,
Jan 22, 2020, 12:03:51 PM1/22/20
to sage-devel
> On Arch, does cblas.pc exist?

Yes.

> this is system-dependent.

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

Isuru

Dima Pasechnik

unread,
Jan 22, 2020, 12:18:26 PM1/22/20
to sage-devel
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

unread,
Jan 22, 2020, 12:20:31 PM1/22/20
to sage-devel
[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

Dima Pasechnik

unread,
Jan 23, 2020, 12:11:51 PM1/23/20
to sage-devel
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

unread,
Jan 23, 2020, 12:18:59 PM1/23/20
to sage-devel
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

unread,
Jan 23, 2020, 12:19:31 PM1/23/20
to sage-devel
> 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

Antonio Rojas

unread,
Jan 23, 2020, 12:36:06 PM1/23/20
to sage-devel


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

unread,
Jan 23, 2020, 1:05:57 PM1/23/20
to sage-devel
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

unread,
Jan 23, 2020, 1:17:49 PM1/23/20
to sage-devel
It depends on the fortran name mangling. For gfortran, one symbol would be dgeqrf_.

Isuru

Dima Pasechnik

unread,
Apr 14, 2020, 9:23:08 AM4/14/20
to sage-devel, nqn...@gmail.com
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

unread,
Apr 14, 2020, 9:28:38 AM4/14/20
to sage-devel
I'm missing some context here... flint does certainly link to ntl already, i don't see how it could work otherwise.

Dima Pasechnik

unread,
Apr 14, 2020, 9:38:27 AM4/14/20
to sage-devel, David Coudert
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

unread,
Apr 14, 2020, 9:47:44 AM4/14/20
to sage-devel
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

unread,
Apr 14, 2020, 9:57:00 AM4/14/20
to sage-devel
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.
Reply all
Reply to author
Forward
0 new messages