Opened 2 years ago

Closed 2 years ago

#21963 closed enhancement (fixed)

Upgrade to pynac-0.7.2

Reported by: rws Owned by:
Priority: major Milestone: sage-7.5
Component: packages: standard Keywords:
Cc: Merged in:
Authors: Ralf Stephan Reviewers: François Bissey
Report Upstream: N/A Work issues:
Branch: 6130c95 (Commits) Commit: 6130c9586fe8c0ca8b80615aec4cb37604b0dbe6
Dependencies: Stopgaps:

Description (last modified by fbissey)

Pynac-0.7.2:

  • add libfactory interface; unconditionally replace GiNaC GCD with Singular (Giac GCD if available); this fixes #10284; it means that Singular is now another Pynac dependency
  • reenable unconditional use of Giac if available (#21885)
  • fix zeta expansion around 1 (behackl) (#21899)
  • fix Giac GCD doctest fail
  • fix NaN unpickling (uncovered in #20939)
  • fix Flint underlinking (fbissey)
  • fix dilog problems (#19906)
  • fix Singular GCD interface
  • fix is_real(positivereal) (#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.

Change History (32)

comment:1 Changed 2 years ago by rws

  • Description modified (diff)

comment:2 Changed 2 years ago by rws

  • Branch set to u/rws/upgrade_to_pynac_0_7_1

comment:3 Changed 2 years ago by rws

  • Authors set to Ralf Stephan
  • Commit set to 738b8a0462099021dc590ae397c5d7b690c9c256
  • Status changed from new to needs_review

New commits:

431bd36update version/chksum
17a471falways set CXXFLAGS=-g -O3; always build/link to Giac if available
f0d8872Singular dependency
83ce083specify namespace in Sage/Pynac interface because of name clash
87d3c90enable/restate GCD doctests
738b8a0doctest changes because of zeta series fix

comment:4 Changed 2 years ago by rws

  • Description modified (diff)

comment:5 Changed 2 years ago by rws

  • Description modified (diff)

comment:6 Changed 2 years ago by rws

  • Description modified (diff)

comment:7 Changed 2 years ago by git

  • Commit changed from 738b8a0462099021dc590ae397c5d7b690c9c256 to d219c67392cc58790d04bdfb9fdbbcdd26b3c9ff

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

74ef6bfMerge branch 'develop' into t/21963/upgrade_to_pynac_0_7_1
d219c67complete NaN handling in interface

comment:8 Changed 2 years ago by frederichan

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)

comment:9 follow-up: Changed 2 years ago by rws

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.

comment:10 Changed 2 years ago by git

  • Commit changed from d219c67392cc58790d04bdfb9fdbbcdd26b3c9ff to 9521c4074e338fc0c42d257453cfb3b7e8cfc076

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

9521c4021963: disable Giac because of problems with versions outside Sage

comment:11 Changed 2 years ago by rws

  • Description modified (diff)

comment:12 Changed 2 years ago by rws

  • Status changed from needs_review to needs_work

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

comment:13 in reply to: ↑ 9 Changed 2 years ago by frederichan

Replying to rws:

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?

comment:14 follow-up: Changed 2 years ago by fbissey

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?

comment:15 follow-up: Changed 2 years ago by fbissey

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.

comment:16 in reply to: ↑ 15 Changed 2 years ago by rws

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

comment:17 in reply to: ↑ 14 Changed 2 years ago by rws

Replying to fbissey:

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.

comment:18 Changed 2 years ago by rws

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

comment:19 Changed 2 years ago by fbissey

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.

comment:20 follow-up: Changed 2 years ago by frederichan

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)

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.

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);])

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.

comment:21 in reply to: ↑ 20 Changed 2 years ago by fbissey

Replying to frederichan:

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.

comment:22 Changed 2 years ago by rws

  • Description modified (diff)
  • Summary changed from Upgrade to pynac-0.7.1 to Upgrade to pynac-0.7.2

comment:23 Changed 2 years ago by git

  • Commit changed from 9521c4074e338fc0c42d257453cfb3b7e8cfc076 to f18936aaaf143414686305a9ad45bee241a8c972

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

3a9756dMerge branch 'develop' into t/21963/upgrade_to_pynac_0_7_1
ff3b355update version/chksum
f18936aadditional doctest changes

comment:24 Changed 2 years ago by rws

  • Status changed from needs_work to needs_review

New commits:

3a9756dMerge branch 'develop' into t/21963/upgrade_to_pynac_0_7_1
ff3b355update version/chksum
f18936aadditional doctest changes

comment:25 Changed 2 years ago by rws

  • Description modified (diff)

comment:26 Changed 2 years ago by fbissey

  • Status changed from needs_review to needs_work

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

comment:27 Changed 2 years ago by git

  • Commit changed from f18936aaaf143414686305a9ad45bee241a8c972 to 6130c9586fe8c0ca8b80615aec4cb37604b0dbe6

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

6130c9521963: pkgconf dependency

comment:28 Changed 2 years ago by rws

  • Status changed from needs_work to needs_review

comment:29 Changed 2 years ago by fbissey

  • Description modified (diff)
  • Reviewers set to François Bissey
  • Status changed from needs_review to positive_review

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

comment:30 follow-up: Changed 2 years ago by rws

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.

comment:31 in reply to: ↑ 30 Changed 2 years ago by fbissey

Replying to rws:

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.

comment:32 Changed 2 years ago by vbraun

  • Branch changed from u/rws/upgrade_to_pynac_0_7_1 to 6130c9586fe8c0ca8b80615aec4cb37604b0dbe6
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.