date:20200122

[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

On Wed, Jan 22, 2020 at 11:18 AM Dima Pasechnik  wrote:

> On Wed, Jan 22, 2020 at 5:03 PM Isuru Fernando  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]
>
>
> >
> > > this is system-dependent.
> >
> > Yes, that's why we need to have fallbacks.
> >
> > Isuru
> >
> > On Wed, Jan 22, 2020 at 11:00 AM Dima Pasechnik 
> wrote:
> >>
> >> On Wed, Jan 22, 2020 at 4:17 PM Isuru Fernando 
> 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?
> >>
> >>
> >> >
> >> > 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
> >> >
> >> > On Wed, Jan 22, 2020 at 10:14 AM Isuru Fernando 
> wrote:
> >> >>
> >> >> > 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 (0x7ffd2f7bb000)
> >> >> libblas.so.3 => /usr/lib/libblas.so.3 (0x7f848f079000)
> >> >> libc.so.6 => /usr/lib/libc.so.6 (0x7f848eeb2000)
> >> >> libm.so.6 => /usr/lib/libm.so.6 (0x7f848ed6c000)
> >> >> libpthread.so.0 => /usr/lib/libpthread.so.0
> (0x7f848ed4a000)
> >> >> libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f848ed11000)
> >> >> /usr/lib64/ld-linux-x86-64.so.2 (0x7f84902dc000)
> >> >> libdl.so.2 => /usr/lib/libdl.so.2 (0x7f848ed0c000)
> >> >>
> >> >> [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
> >> >>
> >> >> On Wed, Jan 22, 2020 at 10:09 AM Dima Pasechnik 
> wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Wed, 22 Jan 2020, 15:59 Isuru Fernando, 
> 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.
> >> >>>
> >> >>>
> >> 
> >>  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
> >> 
> >>  On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik 
> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <
> 20100.delecr...@gmail.com> wrote:
> >> >>
> >> >> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
> >> >> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
> >> >> > <20100.delecr...@gmail.com> wrote:
> >> >> >>
> >> >> >> I had the same annoying trouble... Is it really a bug in
> arch? I don't
> >> >> >> find anywhere wher

Re: [sage-devel] 9.1.beta0 build failure on Arch

On Wed, Jan 22, 2020 at 5:03 PM Isuru Fernando  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]


>
> > this is system-dependent.
>
> Yes, that's why we need to have fallbacks.
>
> Isuru
>
> On Wed, Jan 22, 2020 at 11:00 AM Dima Pasechnik  wrote:
>>
>> On Wed, Jan 22, 2020 at 4:17 PM Isuru Fernando  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?
>>
>>
>> >
>> > 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
>> >
>> > On Wed, Jan 22, 2020 at 10:14 AM Isuru Fernando  wrote:
>> >>
>> >> > 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 (0x7ffd2f7bb000)
>> >> libblas.so.3 => /usr/lib/libblas.so.3 (0x7f848f079000)
>> >> libc.so.6 => /usr/lib/libc.so.6 (0x7f848eeb2000)
>> >> libm.so.6 => /usr/lib/libm.so.6 (0x7f848ed6c000)
>> >> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f848ed4a000)
>> >> libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f848ed11000)
>> >> /usr/lib64/ld-linux-x86-64.so.2 (0x7f84902dc000)
>> >> libdl.so.2 => /usr/lib/libdl.so.2 (0x7f848ed0c000)
>> >>
>> >> [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
>> >>
>> >> On Wed, Jan 22, 2020 at 10:09 AM Dima Pasechnik  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Wed, 22 Jan 2020, 15:59 Isuru Fernando,  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.
>> >>>
>> >>>
>> 
>>  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
>> 
>>  On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik  
>>  wrote:
>> >
>> >
>> >
>> > On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, 
>> > <20100.delecr...@gmail.com> wrote:
>> >>
>> >> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
>> >> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
>> >> > <20100.delecr...@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

Re: [sage-devel] Failure to build 9.0 -- matplotlib error

On Wed, Jan 22, 2020 at 4:59 PM Jeremy Martin  wrote:
>
> Same problem after running .configure and make.  Again, it breaks while 
> trying to build brial.  New log attached.

It seems like you have some old Sage bits in your PATH:

checking pkg-config is at least version 0.9.0...
/Applications/sage-8.4/local/bin/pkg-config

(and this results in an error, as this pkg-config has no idea about
Sage you want to build)

Make sure it's not found.




>
> Thanks again,
> Jeremy
>
> On 1/22/20 9:45 AM, Jeremy Martin wrote:
>
> Just ran ./configure and am about to try make again.  config.log is attached.
>
> -JLM
>
> On Wednesday, January 22, 2020 at 9:31:40 AM UTC-6, Dima Pasechnik wrote:
>>
>> hmm, did you re-run ./configure after these installations?
>>
>> could you post config.log ?
>>
>>
>> On Wed, 22 Jan 2020, 15:19 Jeremy Martin,  wrote:
>>>
>>> Hmm.  I did "brew install libpng" and "brew install pkg-config", then tried 
>>> to build again.  This time make threw an error that pkg-config was not 
>>> installed.  Setting the PKG_CONFIG environment variable does not fix the 
>>> problem.  I'm not sure what is going on, since pkg-config is located in 
>>> /usr/local/bin, which is in both PKG_CONFIG and PATH.
>>>
>>> The logfile is attached.  Thanks again for your help.
>>>
>>> -Jeremy
>>>
>>> On Tuesday, January 21, 2020 at 4:32:48 PM UTC-6, Jeremy Martin wrote:

 Thanks, I did not notice that.  I will try it and report back.

 -Jeremy

 On Tuesday, January 21, 2020 at 2:43:02 PM UTC-6, Dima Pasechnik wrote:
>
> the interesting part of the log is
>
>* The following required packages can not be 
> built:
> * png
> * Try installing png with `brew install 
> libpng` and
> * pkg-config with `brew install pkg-config`
>
> It seems you are building under Homebrew, but something goes wrong with 
> libpng.
> Do you have it installed?
>
> Do you have Sage's libpng built?
>
>
>
>
> On Tue, Jan 21, 2020 at 8:01 PM Jeremy Martin  wrote:
> >
> > I'm trying to build Sage 9.0 from source under MacOS Mojave 10.14.6. I 
> > ran into an error with matplotlib.  The end of the error message is 
> > below, and I'm attaching the logfile.
> >
> > Error building Sage.
> >
> > The following package(s) may have failed to build (not necessarily
> > during this run of 'make all-start'):
> >
> > * package: matplotlib-2.2.4.p0
> >   log file: /Applications/sage-9.0/logs/pkgs/matplotlib-2.2.4.p0.log
> >   build directory: 
> > /Applications/sage-9.0/local/var/tmp/sage/build/matplotlib-2.2.4.p0
> >
> > Any advice you can give will be helpful.  Thanks!
> >
> > --Jeremy Martin
> >
> > --
> > 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/ecd0ca50-ef2d-4d8d-859e-0e746e093b25%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/2cf8de41-abb6-4069-86ec-24d5e7697980%40googlegroups.com.
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "sage-devel" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/sage-devel/u7ON4JnrhGM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/39a9bbd9-e310-410f-8b7f-cb06b465be78%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/d30e13f1-2668-9b08-56b2-7b0cc17fac64%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2u1hNXVTzVMB2WS40wj6F%3DU%2BN_pT%3DrmUE8aU049xVbbQ%40mail.gmail.com.

Re: [sage-devel] 9.1.beta0 build failure on Arch

> On Arch, does cblas.pc exist?

Yes.

> this is system-dependent.

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

Isuru

On Wed, Jan 22, 2020 at 11:00 AM Dima Pasechnik  wrote:

> On Wed, Jan 22, 2020 at 4:17 PM Isuru Fernando  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?
>
>
> >
> > 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
> >
> > On Wed, Jan 22, 2020 at 10:14 AM Isuru Fernando 
> wrote:
> >>
> >> > 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 (0x7ffd2f7bb000)
> >> libblas.so.3 => /usr/lib/libblas.so.3 (0x7f848f079000)
> >> libc.so.6 => /usr/lib/libc.so.6 (0x7f848eeb2000)
> >> libm.so.6 => /usr/lib/libm.so.6 (0x7f848ed6c000)
> >> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f848ed4a000)
> >> libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f848ed11000)
> >> /usr/lib64/ld-linux-x86-64.so.2 (0x7f84902dc000)
> >> libdl.so.2 => /usr/lib/libdl.so.2 (0x7f848ed0c000)
> >>
> >> [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
> >>
> >> On Wed, Jan 22, 2020 at 10:09 AM Dima Pasechnik 
> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, 22 Jan 2020, 15:59 Isuru Fernando,  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.
> >>>
> >>>
> 
>  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
> 
>  On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik 
> wrote:
> >
> >
> >
> > On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <
> 20100.delecr...@gmail.com> wrote:
> >>
> >> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
> >> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
> >> > <20100.delecr...@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

Re: [sage-devel] 9.1.beta0 build failure on Arch

On Wed, Jan 22, 2020 at 4:17 PM Isuru Fernando  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?


>
> 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
>
> On Wed, Jan 22, 2020 at 10:14 AM Isuru Fernando  wrote:
>>
>> > 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 (0x7ffd2f7bb000)
>> libblas.so.3 => /usr/lib/libblas.so.3 (0x7f848f079000)
>> libc.so.6 => /usr/lib/libc.so.6 (0x7f848eeb2000)
>> libm.so.6 => /usr/lib/libm.so.6 (0x7f848ed6c000)
>> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f848ed4a000)
>> libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f848ed11000)
>> /usr/lib64/ld-linux-x86-64.so.2 (0x7f84902dc000)
>> libdl.so.2 => /usr/lib/libdl.so.2 (0x7f848ed0c000)
>>
>> [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
>>
>> On Wed, Jan 22, 2020 at 10:09 AM Dima Pasechnik  wrote:
>>>
>>>
>>>
>>> On Wed, 22 Jan 2020, 15:59 Isuru Fernando,  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.
>>>
>>>

 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

 On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik  wrote:
>
>
>
> On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <20100.delecr...@gmail.com> 
> wrote:
>>
>> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
>> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
>> > <20100.delecr...@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.
>>

Re: [sage-devel] Failure to build 9.0 -- matplotlib error

2020-01-22 Thread Jeremy Martin

Same problem after running .configure and make.  Again, it breaks while 
trying to build brial.  New log attached.


Thanks again,
Jeremy

On 1/22/20 9:45 AM, Jeremy Martin wrote:
Just ran ./configure and am about to try make again.  config.log is 
attached.


-JLM

On Wednesday, January 22, 2020 at 9:31:40 AM UTC-6, Dima Pasechnik wrote:

hmm, did you re-run ./configure after these installations?

could you post config.log ?


On Wed, 22 Jan 2020, 15:19 Jeremy Martin, > wrote:

Hmm.  I did "brew install libpng" and "brew install
pkg-config", then tried to build again. This time make threw
an error that pkg-config was not installed.  Setting the
PKG_CONFIG environment variable does not fix the problem.  I'm
not sure what is going on, since pkg-config is located in
/usr/local/bin, which is in both PKG_CONFIG and PATH.

The logfile is attached.  Thanks again for your help.

-Jeremy

On Tuesday, January 21, 2020 at 4:32:48 PM UTC-6, Jeremy
Martin wrote:

Thanks, I did not notice that.  I will try it and report
back.

-Jeremy

On Tuesday, January 21, 2020 at 2:43:02 PM UTC-6, Dima
Pasechnik wrote:

the interesting part of the log is

                           * The following required
packages can not be built:
                            * png
                            * Try installing png with
`brew install libpng` and
                            * pkg-config with `brew
install pkg-config`

It seems you are building under Homebrew, but
something goes wrong with libpng.
Do you have it installed?

Do you have Sage's libpng built?




On Tue, Jan 21, 2020 at 8:01 PM Jeremy Martin
 wrote:
>
> I'm trying to build Sage 9.0 from source under MacOS
Mojave 10.14.6. I ran into an error with matplotlib. 
The end of the error message is below, and I'm
attaching the logfile.
>
> Error building Sage.
>
> The following package(s) may have failed to build
(not necessarily
> during this run of 'make all-start'):
>
> * package: matplotlib-2.2.4.p0
>   log file:
/Applications/sage-9.0/logs/pkgs/matplotlib-2.2.4.p0.log
>   build directory:

/Applications/sage-9.0/local/var/tmp/sage/build/matplotlib-2.2.4.p0

>
> Any advice you can give will be helpful.  Thanks!
>
> --Jeremy Martin
>
> --
> 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/ecd0ca50-ef2d-4d8d-859e-0e746e093b25%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/2cf8de41-abb6-4069-86ec-24d5e7697980%40googlegroups.com

.

--
You received this message because you are subscribed to a topic in the 
Google Groups "sage-devel" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/sage-devel/u7ON4JnrhGM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
sage-devel+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/39a9bbd9-e310-410f-8b7f-cb06b465be78%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+unsubscr...@googlegroups.com.
To view this dis

[sage-devel] Re: Power series do not distinguish between different precisions!

2020-01-22 Thread Nils Bruin

 On Wednesday, January 22, 2020 at 5:07:18 AM UTC-8, Marc Mezzarobba wrote:

> Perhaps more importantly, I find the fact that series and p-adics (but 
> not intervals and balls) are doing that problematic for writing generic 
> code. Suppose that a is a symbolic expression, or an element of any 
> other parent where inequality is not decidable. Would you expect 
> a.is_zero() to return True whenever Sage is unable to prove that a is 
> nonzero? If not, what can code written for generic coefficient rings do 
> to work with both expressions and series? 
>

It has the big advantage that if you compute a root of a polynomial, then 
evaluating the polynomial at that root will give you a result that is equal 
to zero. That's extremely useful in for instance writing routines that test 
local solvability. It also means that if you assume you've started out with 
enough precision to distinguish any non-equal elements that occur in your 
computation, then equality gives you a reliable result.

Under the assumption you are starting out with sufficient excess precision 
to start, I think it's actually the model that makes generic algorithms 
still work: even gaussian elimination works properly "in the limit"; 
without some numerical stability tricks it likely just needs ridiculous 
amounts of initial precision.

I don't think that for any non-trivial applications generic code is going 
to perform properly for both exact and non-exact base rings, but actually 
the equality choice that has been made, allows the heuristic approach: 
start with very high precision or double the precision a couple of times 
and see if results stabilize. This can be extremely useful in getting some 
experimental verification of conjectures.

>
> Regarding power series in particular, the structure where 
> cos(sin(tan(t^2)) - tan(sin(t^2))) == 1 exists and makes perfect sense, 
> but it's the ring of polynomials mod t^20, not the ring of power series 
> with precision 20. 
>
> -- 
> Marc 
>
>
On Wednesday, January 22, 2020 at 5:07:18 AM UTC-8, Marc Mezzarobba wrote:
>
> [re-posting a reply from a week ago that apparently did not go through 
> because gmane was moving] 
>
> Nils Bruin wrote: 
> > This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns 
> > true, as one would expect mathematically. 
>
> Do you mean it has the advantage that cos(sin(tan(t^2)) - 
> tan(sin(t^2))) == 1 returns True, as one would expect mathematically? 
> ;-) 
>
> Joking aside, if I hadn't be hit by that issue before, I would also 
> expect to be able to trust equality more than that. And I would 
> interpret the presence of an explicit O() term as a strong indication 
> that inexact series won't be considered equal to anything. 
>
> Perhaps more importantly, I find the fact that series and p-adics (but 
> not intervals and balls) are doing that problematic for writing generic 
> code. Suppose that a is a symbolic expression, or an element of any 
> other parent where inequality is not decidable. Would you expect 
> a.is_zero() to return True whenever Sage is unable to prove that a is 
> nonzero? If not, what can code written for generic coefficient rings do 
> to work with both expressions and series? 
>
> Regarding power series in particular, the structure where 
> cos(sin(tan(t^2)) - tan(sin(t^2))) == 1 exists and makes perfect sense, 
> but it's the ring of polynomials mod t^20, not the ring of power series 
> with precision 20. 
>
> -- 
> Marc 
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/71523992-f72d-4d1a-8981-7e05ad2613f7%40googlegroups.com.

Re: [sage-devel] 9.1.beta0 build failure on Arch

> 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

On Wed, Jan 22, 2020 at 10:14 AM Isuru Fernando  wrote:

> > 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 (0x7ffd2f7bb000)
> libblas.so.3 => /usr/lib/libblas.so.3 (0x7f848f079000)
> libc.so.6 => /usr/lib/libc.so.6 (0x7f848eeb2000)
> libm.so.6 => /usr/lib/libm.so.6 (0x7f848ed6c000)
> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f848ed4a000)
> libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f848ed11000)
> /usr/lib64/ld-linux-x86-64.so.2 (0x7f84902dc000)
> libdl.so.2 => /usr/lib/libdl.so.2 (0x7f848ed0c000)
>
> [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
>
> On Wed, Jan 22, 2020 at 10:09 AM Dima Pasechnik  wrote:
>
>>
>>
>> On Wed, 22 Jan 2020, 15:59 Isuru Fernando,  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.
>>
>>
>>
>>> 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
>>>
>>> On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik 
>>> wrote:
>>>


 On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <
 20100.delecr...@gmail.com> wrote:

> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
> > <20100.delecr...@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 t

Re: [sage-devel] 9.1.beta0 build failure on Arch

> 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 (0x7ffd2f7bb000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x7f848f079000)
libc.so.6 => /usr/lib/libc.so.6 (0x7f848eeb2000)
libm.so.6 => /usr/lib/libm.so.6 (0x7f848ed6c000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f848ed4a000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f848ed11000)
/usr/lib64/ld-linux-x86-64.so.2 (0x7f84902dc000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x7f848ed0c000)

[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

On Wed, Jan 22, 2020 at 10:09 AM Dima Pasechnik  wrote:

>
>
> On Wed, 22 Jan 2020, 15:59 Isuru Fernando,  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.
>
>
>
>> 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
>>
>> On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik  wrote:
>>
>>>
>>>
>>> On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <20100.delecr...@gmail.com>
>>> wrote:
>>>
 Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
 > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
 > <20100.delecr...@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.

>>>
>>> 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  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,  wrote:
 >>
 >> I suspect this may be due to our

Re: [sage-devel] 9.1.beta0 build failure on Arch

On Wed, 22 Jan 2020, 15:59 Isuru Fernando,  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.



> 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
>
> On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik  wrote:
>
>>
>>
>> On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <20100.delecr...@gmail.com>
>> wrote:
>>
>>> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
>>> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
>>> > <20100.delecr...@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.
>>>
>>
>> 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  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,  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+unsubscr...@googlegroups.com.
>>>  To view this discussion on the web visit
>>> https://groups.google.com/

Re: [sage-devel] 9.1.beta0 build failure on Arch

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

On Wed, Jan 22, 2020 at 9:13 AM Vincent Delecroix <20100.delecr...@gmail.com>
wrote:

> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
> > <20100.delecr...@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.
>
> >>
> >> Le 13/01/2020 à 11:44, Dima Pasechnik a écrit :
> >>> On Sat, Jan 11, 2020 at 11:35 AM arojas  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,  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+unsubscr...@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+unsubscr...@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+unsubscr...@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
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CA%2B01voMdYrJZG2Pa5t56KLAxUcTV2cLtY64snE%2BGwBcALh%3DX-Q%40mail.gmail.com.

Re: [sage-devel] 9.1.beta0 build failure on Arch

> 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

On Wed, Jan 22, 2020 at 9:27 AM Dima Pasechnik  wrote:

>
>
> On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <20100.delecr...@gmail.com>
> wrote:
>
>> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
>> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
>> > <20100.delecr...@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.
>>
>
> 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  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,  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+unsubscr...@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+unsubscr...@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

Re: [sage-devel] 9.1.beta0 build failure on Arch

2020-01-22 Thread 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.
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/434aead0-ed50-4151-8d17-d6091b9917f5%40googlegroups.com.

Re: [sage-devel] Failure to build 9.0 -- matplotlib error

hmm, did you re-run ./configure after these installations?

could you post config.log ?


On Wed, 22 Jan 2020, 15:19 Jeremy Martin,  wrote:

> Hmm.  I did "brew install libpng" and "brew install pkg-config", then
> tried to build again.  This time make threw an error that pkg-config was
> not installed.  Setting the PKG_CONFIG environment variable does not fix
> the problem.  I'm not sure what is going on, since pkg-config is located in
> /usr/local/bin, which is in both PKG_CONFIG and PATH.
>
> The logfile is attached.  Thanks again for your help.
>
> -Jeremy
>
> On Tuesday, January 21, 2020 at 4:32:48 PM UTC-6, Jeremy Martin wrote:
>>
>> Thanks, I did not notice that.  I will try it and report back.
>>
>> -Jeremy
>>
>> On Tuesday, January 21, 2020 at 2:43:02 PM UTC-6, Dima Pasechnik wrote:
>>>
>>> the interesting part of the log is
>>>
>>>* The following required packages can not be
>>> built:
>>> * png
>>> * Try installing png with `brew install
>>> libpng` and
>>> * pkg-config with `brew install pkg-config`
>>>
>>> It seems you are building under Homebrew, but something goes wrong with
>>> libpng.
>>> Do you have it installed?
>>>
>>> Do you have Sage's libpng built?
>>>
>>>
>>>
>>>
>>> On Tue, Jan 21, 2020 at 8:01 PM Jeremy Martin 
>>> wrote:
>>> >
>>> > I'm trying to build Sage 9.0 from source under MacOS Mojave 10.14.6. I
>>> ran into an error with matplotlib.  The end of the error message is below,
>>> and I'm attaching the logfile.
>>> >
>>> > Error building Sage.
>>> >
>>> > The following package(s) may have failed to build (not necessarily
>>> > during this run of 'make all-start'):
>>> >
>>> > * package: matplotlib-2.2.4.p0
>>> >   log file: /Applications/sage-9.0/logs/pkgs/matplotlib-2.2.4.p0.log
>>> >   build directory:
>>> /Applications/sage-9.0/local/var/tmp/sage/build/matplotlib-2.2.4.p0
>>> >
>>> > Any advice you can give will be helpful.  Thanks!
>>> >
>>> > --Jeremy Martin
>>> >
>>> > --
>>> > 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/ecd0ca50-ef2d-4d8d-859e-0e746e093b25%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/2cf8de41-abb6-4069-86ec-24d5e7697980%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0bL7owMhkLgiE0W3FJO1%2BcfwTnK21QHpXdyOHWP3-OZw%40mail.gmail.com.

Re: [sage-devel] 9.1.beta0 build failure on Arch

On Wed, 22 Jan 2020, 15:12 Vincent Delecroix, <20100.delecr...@gmail.com>
wrote:

> Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :
> > On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
> > <20100.delecr...@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.
>

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  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,  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+unsubscr...@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+unsubscr...@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+unsubscr...@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
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3p7x9KmwHLmhjOtuoy_3PdsohHN6RJ0fp0Bzxv-wHODQ%40mail.gmail.com.

Re: [sage-devel] Failure to build 9.0 -- matplotlib error

2020-01-22 Thread Jeremy Martin

Hmm.  I did "brew install libpng" and "brew install pkg-config", then tried 
to build again.  This time make threw an error that pkg-config was not 
installed.  Setting the PKG_CONFIG environment variable does not fix the 
problem.  I'm not sure what is going on, since pkg-config is located in 
/usr/local/bin, which is in both PKG_CONFIG and PATH.

The logfile is attached.  Thanks again for your help.

-Jeremy

On Tuesday, January 21, 2020 at 4:32:48 PM UTC-6, Jeremy Martin wrote:
>
> Thanks, I did not notice that.  I will try it and report back.
>
> -Jeremy
>
> On Tuesday, January 21, 2020 at 2:43:02 PM UTC-6, Dima Pasechnik wrote:
>>
>> the interesting part of the log is 
>>
>>* The following required packages can not be 
>> built: 
>> * png 
>> * Try installing png with `brew install 
>> libpng` and 
>> * pkg-config with `brew install pkg-config` 
>>
>> It seems you are building under Homebrew, but something goes wrong with 
>> libpng. 
>> Do you have it installed? 
>>
>> Do you have Sage's libpng built? 
>>
>>
>>
>>
>> On Tue, Jan 21, 2020 at 8:01 PM Jeremy Martin  
>> wrote: 
>> > 
>> > I'm trying to build Sage 9.0 from source under MacOS Mojave 10.14.6. I 
>> ran into an error with matplotlib.  The end of the error message is below, 
>> and I'm attaching the logfile. 
>> > 
>> > Error building Sage. 
>> > 
>> > The following package(s) may have failed to build (not necessarily 
>> > during this run of 'make all-start'): 
>> > 
>> > * package: matplotlib-2.2.4.p0 
>> >   log file: /Applications/sage-9.0/logs/pkgs/matplotlib-2.2.4.p0.log 
>> >   build directory: 
>> /Applications/sage-9.0/local/var/tmp/sage/build/matplotlib-2.2.4.p0 
>> > 
>> > Any advice you can give will be helpful.  Thanks! 
>> > 
>> > --Jeremy Martin 
>> > 
>> > -- 
>> > 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/ecd0ca50-ef2d-4d8d-859e-0e746e093b25%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2cf8de41-abb6-4069-86ec-24d5e7697980%40googlegroups.com.
Found local metadata for brial-1.2.5
Using cached file /Applications/sage-9.0/upstream/brial-1.2.5.tar.bz2
brial-1.2.5

Setting up build directory for brial-1.2.5
Finished extraction
No patch files found in ../patches

Host system:
Darwin MATH-2QM1DHGG77 18.7.0 Darwin Kernel Version 18.7.0: Sun Dec  1 18:59:03 
PST 2019; root:xnu-4903.278.19~1/RELEASE_X86_64 x86_64

C compiler: gcc
C compiler version:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Package 'brial' is currently not installed
Uninstalling 'brial' with legacy uninstaller
Cleaning out old PolyBoRi and BRiAl installations
Configuring brial-1.2.5
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '549304207' is supported by ustar format... no
checking whether GID '1780884004' is supported by ustar format... no
checking how to create a ustar tar archive... none
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking the archiver (ar) interfac

Re: [sage-devel] 9.1.beta0 build failure on Arch

Le 22/01/2020 à 15:41, Dima Pasechnik a écrit :

On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
<20100.delecr...@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.

Le 13/01/2020 à 11:44, Dima Pasechnik a écrit :

On Sat, Jan 11, 2020 at 11:35 AM arojas 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, 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+unsubscr...@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.

Re: [sage-devel] 9.1.beta0 build failure on Arch

On Wed, Jan 22, 2020 at 2:31 PM Vincent Delecroix
<20100.delecr...@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  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,  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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq02FOgjBn-ds_MOOmw3aAVTp2m%3DgA4tBuweNsqKXB8m_Q%40mail.gmail.com.

Re: [sage-devel] 9.1.beta0 build failure on Arch

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?

Le 22/01/2020 à 16:31, Vincent Delecroix a écrit :

Le 13/01/2020 à 11:44, Dima Pasechnik a écrit :

On Sat, Jan 11, 2020 at 11:35 AM arojas 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, 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.

--
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+unsubscr...@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.

Re: [sage-devel] 9.1.beta0 build failure on Arch

Le 13/01/2020 à 11:44, Dima Pasechnik a écrit :

On Sat, Jan 11, 2020 at 11:35 AM arojas 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, 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.

Re: [sage-devel] fail to build fflas_ffpack on 9.1. beta1

The reason for the error seems to be that the pkgconfig
are pointing to my system pkgconfig (which are of not writable)

$ ls -l /opt/sage/local/lib/pkgconfig/
total 52
lrwxrwxrwx 1 vincent vincent 30 22 janv. 15:59 blas.pc ->
/usr/lib/pkgconfig/openblas.pc
lrwxrwxrwx 1 vincent vincent 30 22 janv. 15:59 cblas.pc ->
/usr/lib/pkgconfig/openblas.pc
lrwxrwxrwx 1 vincent vincent 30 22 janv. 15:59 lapack.pc ->
/usr/lib/pkgconfig/openblas.pc

-rw-r--r-- 1 vincent vincent 517 22 janv. 16:07 openblas.pc
lrwxrwxrwx 1 vincent vincent 13 22 janv. 16:02 python-3.7m.pc ->
python-3.7.pc

lrwxrwxrwx 1 vincent vincent 13 22 janv. 16:02 python3.pc -> python-3.7.pc

Le 22/01/2020 à 16:17, Vincent Delecroix a écrit :

This was not the error (just a warning). Problem is

cp: cannot create regular file
'/opt/sage/local/./lib/pkgconfig/blas.pc': Permission denied
cp: cannot create regular file
'/opt/sage/local/./lib/pkgconfig/cblas.pc': Permission denied
cp: cannot create regular file
'/opt/sage/local/./lib/pkgconfig/lapack.pc': Permission denied

Le 22/01/2020 à 16:16, Vincent Delecroix a écrit :

With the option --without-system-openblas, the compilation fails at
openblas with

getarch.c:96: warning: "NO_AVX512" redefined
96 | #define NO_AVX512

(see also attachment)

Vincent

Le 22/01/2020 à 13:46, Dima Pasechnik a écrit :

there was a thread
https://groups.google.com/d/msg/sage-devel/pIOnFyFJMtM/_FbzM2OxCQAJ
just on this 10 days ago.

the system's openblas on Arch is broken, so you'd need to build with
---without-system-openblas

and also it might be related to
https://trac.sagemath.org/ticket/27444#comment:34

On Wed, Jan 22, 2020 at 12:27 PM Vincent Delecroix
<20100.delecr...@gmail.com> wrote:

Dear all,

I am experiencing trouble compiling fflas_ffpack (in the sage
compilation process). It is the same error appearing multiple
times related to openblas_set_num_threads being not declared.

Note that I am running archlinux.

Best
Vincent

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/6d203341-930b-c660-ca0e-c743cda11a56%40gmail.com.

Re: [sage-devel] fail to build fflas_ffpack on 9.1. beta1

This was not the error (just a warning). Problem is

Le 22/01/2020 à 16:16, Vincent Delecroix a écrit :

With the option --without-system-openblas, the compilation fails at
openblas with

getarch.c:96: warning: "NO_AVX512" redefined
96 | #define NO_AVX512

(see also attachment)

Vincent

Le 22/01/2020 à 13:46, Dima Pasechnik a écrit :

there was a thread
https://groups.google.com/d/msg/sage-devel/pIOnFyFJMtM/_FbzM2OxCQAJ
just on this 10 days ago.

the system's openblas on Arch is broken, so you'd need to build with
---without-system-openblas

and also it might be related to
https://trac.sagemath.org/ticket/27444#comment:34

On Wed, Jan 22, 2020 at 12:27 PM Vincent Delecroix
<20100.delecr...@gmail.com> wrote:

Dear all,

I am experiencing trouble compiling fflas_ffpack (in the sage
compilation process). It is the same error appearing multiple
times related to openblas_set_num_threads being not declared.

Note that I am running archlinux.

Best
Vincent

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/6d203341-930b-c660-ca0e-c743cda11a56%40gmail.com.

[sage-devel] Re: Coercions of polynomials

2020-01-22 Thread Marc Mezzarobba

[re-posting a reply from a week ago that apparently did not go through 
because of the gmane move]

David Roe wrote:
>> So one thing I thought of that could be a problem is this:
>>
>> ZZ['x'] --> ZZ['x,y']['x']
>>
>> or more generally anytime there are repeated variable names.
>> Actually, in this case, I feel the default should be to go into the
>> base ring rather than the final ring, but another option would be to
>> just error out and say it is ambiguous.
> 
> I think an error is best.  Users can always use lists if they really
> want to do something like this.

Since we have no real mechanism for creating fresh indeterminates, 
raising and error here would really complicate code written for 
univariate polynomial rings over generic base rings.

-- 
Marc

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/r09hle%24poi%241%40ciao.gmane.io.

[sage-devel] Re: Power series do not distinguish between different precisions!

2020-01-22 Thread Marc Mezzarobba

[re-posting a reply from a week ago that apparently did not go through 
because gmane was moving]

Nils Bruin wrote:
> This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns
> true, as one would expect mathematically.

Do you mean it has the advantage that cos(sin(tan(t^2)) - 
tan(sin(t^2))) == 1 returns True, as one would expect mathematically? 
;-)

Joking aside, if I hadn't be hit by that issue before, I would also 
expect to be able to trust equality more than that. And I would 
interpret the presence of an explicit O() term as a strong indication 
that inexact series won't be considered equal to anything.

Perhaps more importantly, I find the fact that series and p-adics (but 
not intervals and balls) are doing that problematic for writing generic 
code. Suppose that a is a symbolic expression, or an element of any 
other parent where inequality is not decidable. Would you expect 
a.is_zero() to return True whenever Sage is unable to prove that a is 
nonzero? If not, what can code written for generic coefficient rings do 
to work with both expressions and series?

Regarding power series in particular, the structure where
cos(sin(tan(t^2)) - tan(sin(t^2))) == 1 exists and makes perfect sense, 
but it's the ring of polynomials mod t^20, not the ring of power series 
with precision 20.

-- 
Marc

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/r09gso%2430f0%241%40ciao.gmane.io.

Re: [sage-devel] fail to build fflas_ffpack on 9.1. beta1