Upgrade to pynac-0.7.2

[rwst]

Pynac-0.7.2:

• add libfactory interface; unconditionally replace GiNaC GCD with Singular (Giac GCD if available); this fixes Infinite loop in gcd() via pynac-0.2.1 #10284; it means that Singular is now another Pynac dependency
• reenable unconditional use of Giac if available (Enable Pynac's Giac support #21885)
• fix zeta expansion around 1 (behackl) (Document Stieltjes constants #21899)
• fix Giac GCD doctest fail
• fix NaN unpickling (uncovered in Fix crash and remove pexpect-Maxima usage in Y(m,n) #20939)
• fix Flint underlinking (fbissey)
• fix dilog problems (Doctest fix for: dilog(RR) should return an element of RR #19906)
• fix Singular GCD interface
• fix is_real(positive^real) (Doctest for: Positive raised by a positive power is not known to be real #21940)
• better error message with evalf of some orthogonal polys
• improve pkg-config usage
• add internal rising/falling factorial

Tarball: https://github.com/pynac/pynac/releases/download/pynac-0.7.2/pynac-0.7.2.tar.bz2

Needs to specifically tested on Debian/Ubuntu because of #21885.

Component: packages: standard

Author: Ralf Stephan

Branch/Commit: 6130c95

Reviewer: François Bissey

Issue created by migration from https://trac.sagemath.org/ticket/21963

[rwst]

Branch: u/rws/upgrade_to_pynac_0_7_1

[rwst]

Author: Ralf Stephan

[rwst]

New commits:

431bd36	update version/chksum
17a471f	always set CXXFLAGS=-g -O3; always build/link to Giac if available
f0d8872	Singular dependency
83ce083	specify namespace in Sage/Pynac interface because of name clash
87d3c90	enable/restate GCD doctests
738b8a0	doctest changes because of zeta series fix

[rwst]

Commit: 738b8a0

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

74ef6bf	Merge branch 'develop' into t/21963/upgrade_to_pynac_0_7_1
d219c67	complete NaN handling in interface

[sagetrac-git]

Changed commit from 738b8a0 to d219c67

[frederichan-IMJPRG]

comment:8

Hi ralf, I think that with this pynac the giac spkg must be a dependency.

Indeed, I have tried to build sage on a system which have also a version of giac that I am not allowed to remove (and no control of how it was built). In my case it was bernard parisse's binary package installed by root. So this version of libgiac was built with all options and with libao support, but the libao headers were not installed on my system.

But now when building sage, pynac found this unexpected giac and the built was broken because of libao problems.

Then installing also the giac spkg and the built of sage is going further (although I have not finshed yet)

[rwst]

comment:9

Thanks for the effort Frédéric.

Giac is not a standard package so can be no dependency. Pynac needs to detect such Giac versions that cannot be linked to. As I think this is more tricky we will disable Giac again and reenable in a later version when a solution is found.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

9521c40

21963: disable Giac because of problems with versions outside Sage

[sagetrac-git]

Changed commit from d219c67 to 9521c40

[rwst]

comment:12

Problems in the Singular interface were found. A new version is necessary.

[frederichan-IMJPRG]

comment:13

Replying to @rwst:

Thanks for the effort Frédéric.

Giac is not a standard package so can be no dependency. Pynac needs to detect such Giac versions that cannot be linked to. As I think this is more tricky we will disable Giac again and reenable in a later version when a solution is found.

I don't know the procedure for giac to become a standard package, but it may be the more natural solution. I can see that Francois Bissey is already updating giac often in sage-on-gentoo:
http://gpo.zugaina.org/sci-mathematics/giac/ChangeLog

About the broken built I can give more details:
The point is that my system have a:
/usr/lib/libgiac.la file containing this line:

# Libraries that this one depends upon.
dependency_libs=' -lntl -lpari -lgsl -lgslcblas -lrt -lpthread -lao -lblas -ldl -lpng -lmpfi -lmpfr -lgmp'

and the pynac built broke there:

  CXXLD    libpynac.la
/usr/bin/ld: cannot find -lao
collect2: error: ld returned 1 exit status
Makefile:496: recipe for target 'libpynac.la' failed

Now I am testing the following:
I put a copy of this libgiac.la in your ginac dir but removed the -lao and -lblas tags.
Then I can build pynac without the giac spkg on this system and I have:

zeta(han)$ ldd local/lib/libpynac.so.9
	linux-vdso.so.1 (0x00007ffe10db9000)
	libpython2.7.so.1.0 => /home/han/dev/sage-brouillon/local/lib/libpython2.7.so.1.0 (0x00007f1027917000)
	libfactory-4.0.3.so => /home/han/dev/sage-brouillon/local/lib/libfactory-4.0.3.so (0x00007f1027555000)
	libflint.so.13 => /home/han/dev/sage-brouillon/local/lib/libflint.so.13 (0x00007f1026e8b000)
	libgmp.so.16 => /home/han/dev/sage-brouillon/local/lib/libgmp.so.16 (0x00007f1026c17000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f102690c000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f102660b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1026260000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f102604a000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1025e2d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1025c29000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f1025a26000)
	libsingular_resources-4.0.3.so => /home/han/dev/sage-brouillon/local/lib/libsingular_resources-4.0.3.so (0x00007f1025821000)
	libomalloc-0.9.6.so => /home/han/dev/sage-brouillon/local/lib/libomalloc-0.9.6.so (0x00007f1025617000)
	libmpfr.so.4 => /home/han/dev/sage-brouillon/local/lib/libmpfr.so.4 (0x00007f10253bb000)
	libntl.so.31 => /home/han/dev/sage-brouillon/local/lib/libntl.so.31 (0x00007f1024f8b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f102813b000)
	libgf2x.so.1 => /home/han/dev/sage-brouillon/local/lib/libgf2x.so.1 (0x00007f1024d73000)

so it doesn't seem to be linked with this external giac?

[kiwifb]

comment:14

Bloody .la files. They shouldn't be shipped. If giac is made a standard sage package it should be found and used before the system one thanks to CPATH and RPATH settings. The configure script should detect whether or not giac can be used.

I inspected giac's headers and it doesn't include libao headers in any way. But without libao dev package you probably don't have libao.so installed.

After thinking about it I find curious that you have libgiac.so available on your system but not libao.so. libgiac.so should be in a dev package and that dev package should pull all the dependent dev packages otherwise it cannot be working. Was giac installed manually (not with the package manager) by your admin?

[kiwifb]

comment:15

There are other small minor problems with pynac's .pc file. Now that you depend on flint, there should be a -lflint somewhere in the .pc file. If you use factory I would recommend to pull its configuration from factory.pc rather than what you do now. Then factory would have to be added in pynac.pc as a Requires: line (as a bonus it looks like factory depends on flint unconditionally so you would get -lflint for free from factory.pc in the output of pkg-config --libs pynac). I may be able to work on those problems from Tuesday.

[rwst]

comment:16

That would be awesome. The next release will take some time anyway.

[rwst]

comment:17

Replying to @kiwifb:

Bloody .la files. They shouldn't be shipped.

It seems that a broken libtool is the cause: https://lists.fedoraproject.org/pipermail/devel/2010-November/146343.html
Maybe the ld flag -no-add-needed when compiling giac has an effect but that wouldn't affect existing .la files.

The other alternative, removing or changing the .la file before linking would be an idea but that looks unusual or hackish.

[rwst]

comment:18

So the safe method seems in configure to detect -lao in the .la file and disable Giac in case.

[kiwifb]

comment:19

Possibly, but I think there is something broken in the system where the problem was shown. Applications and the giac binaries don't need libgiac.so or libao.so. They use libgiac.so.0 and libao.so.X (X is 4 for me). libgiac.so should only be available in a giac-xxx-dev or giac-xxx-devel package. This one in turn should pull the required dev/devel packages for the dependencies.

If it doesn't currently work that way, whoever built the package logic had it wrong.

[kiwifb]

comment:21

Replying to @frederichan-IMJPRG:

I think that no problems were reported with the giac spkg installed before pynac built, even if there is a system wide (broken or not) libgiac.
I guess that in all reported cases the libgiac in /usr/lib was from B. Parisse's binary package:
http://www-fourier.ujf-grenoble.fr/~parisse/debian/
(but it may happen often, for example when people also want xcas; I think it is also on sagemath cloud)

I am not surprised.

indeed it is an all in one package with libgiac.so linked to libao.so.4. But I think we could have more problems than just the libao-dev not installed. For instance it is built with some gcc<5 and I have problems with strings if I use gcc5 without a CXXFLAGS with -D_GLIBCXX_USE_CXX11_ABI=0 with parisse's package and the giac spkg not installed.

ABI problem, yes that's hard.

So you should also test in your configure a small program with a giac::gen initialized with a string.
Ex:

AC_LANG_PROGRAM([#include <giac/giac.h>], 
    [giac::context ct;
     giac::gen g(std::string("0"),&ct);])

That looks a good idea to me.

NB: Sorry my ldd in comment 13 was not correct, unfortunately if I built pynac without the giac spkg but with parisse's giac .deb (with a modified libgiac.la in ginac/ and with gcc4.9) then pynac is linked to this /usr/lib/libgiac...

If I remember some discussion someone also wanted pynac to not be linked to an external library so that you can make binary distributions of sage so I think that you should enable giac only with the spkg or in distrib like fedora where you have a offical package.

I am the one who actually said it should happen that way at the sage binary package level.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

3a9756d	Merge branch 'develop' into t/21963/upgrade_to_pynac_0_7_1
ff3b355	update version/chksum
f18936a	additional doctest changes

[sagetrac-git]

Changed commit from 9521c40 to f18936a

[rwst]

New commits:

3a9756d	Merge branch 'develop' into t/21963/upgrade_to_pynac_0_7_1
ff3b355	update version/chksum
f18936a	additional doctest changes

[kiwifb]

comment:26

Dependency needs to include pkgconf as the pkg-config command needs to be there at configuration time.

[sagetrac-git]

Changed commit from f18936a to 6130c95

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

6130c95

21963: pkgconf dependency

[kiwifb]

Reviewer: François Bissey

[kiwifb]

comment:29

The bot will take care of testing debian/ubuntu I guess. But yes one of the next step will be more robust detection of a working giac which may be a standard package in 7.5....

[rwst]

comment:30

Thanks. Unfortunately I didn't switch on the Giac support in Pynac in this ticket so anything Giac (with it being standard package now) will have to wait for the next Pynac release.

[kiwifb]

comment:31

Replying to @rwst:

Thanks. Unfortunately I didn't switch on the Giac support in Pynac in this ticket so anything Giac (with it being standard package now) will have to wait for the next Pynac release.

That's OK. In my opinion there are two more things to do before switching giac on properly. 1) more robust detection so we definitely don't get non-working version. That will help distros mostly since the availability of giac as standard in sage solves the problem of the poisonous debian one. 2) More changes are needed in pynac.pc - will need to add the library there as well when enabled.

[vbraun]

Changed branch from u/rws/upgrade_to_pynac_0_7_1 to 6130c95