Opened 17 months ago

Closed 13 months ago

Last modified 12 months ago

#26315 closed defect (fixed)

Upgrade to Giac 1.5

Reported by: slelievre Owned by:
Priority: major Milestone: sage-8.7
Component: packages: standard Keywords: upgrade, giac
Cc: arojas, fbissey, frederichan, infinity0, saraedum, thansen, gh-timokau Merged in:
Authors: Dima Pasechnik Reviewers: François Bissey, Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: 5986d80 (Commits) Commit:
Dependencies: Stopgaps:

Description (last modified by dimpase)

This ticket is to upgrade to Giac 1.5.

A preliminary version "1.5.0 unstable" is available for testing:

This upgrade should solve #25822 and #25324 since the issues reported there are fixed upstream.

All that will be left to do in those tickets is add doctests.

I suppose we finally have stable 1.5.0, here

(repacked):

tarball: http://users.ox.ac.uk/~coml0531/sage/giac-1.5.0.37.tar.bz2

Attachments (2)

giac-1.5.0-3.clang601.patch (2.6 KB) - added by dimpase 16 months ago.
patch needed for giac to build with clang 6.0.1 (possibly incomplete)
giac-1.5.0.patch (410 bytes) - added by gh-symphorien 15 months ago.

Download all attachments as: .zip

Change History (80)

comment:1 Changed 17 months ago by frederichan

NB: I have reported in giac's forum that without glpk the built of:

http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.5.0-1.tar.gz

is broken. This is a minor change in src/graphe.cc, but may be we could wait 1.5.0-2?

Whatever, we never use the "unstable" file https://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.5.0.tar.gz for packaging because it changes often.

cf: http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/README

comment:2 Changed 17 months ago by slelievre

  • Description modified (diff)

comment:3 Changed 17 months ago by slelievre

Thanks frederichan for your comments and the link to the readme.

Of course it does not seem reasonable to upgrade to giac-1.5.0-1.

But I thought I'd at least open the ticket if only to point out that upgrading to giac 1.5 should fix two other tickets.

comment:5 Changed 17 months ago by fbissey

Looking at 1.5.0-3 here. I have libsamplerate-0.1.9 installed on the machine and I discovered that it is one of the new automagically detected configure option (on if you have it). Building giac failed until I passed --disable-samplerate at configure time. Unstable indeed.

comment:6 follow-up: Changed 17 months ago by frederichan

Hi Francois, I didn't knew about this one. Should I report something? (if yes what?)

But I know that glpk and nauty are new possible dependencies. As they standard sage packages, may be we should add them to giac's deps in sage?

Frederic

comment:7 in reply to: ↑ 6 Changed 17 months ago by fbissey

Replying to frederichan:

Hi Francois, I didn't knew about this one. Should I report something? (if yes what?)

Possibly. It may be also be because gcc-8 is more strict about some stuff.

libtool: compile:  x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -DIN_GIAC -I. -I.. -I. -I.. -g -O2 -fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS -c signalprocessing.cc  -fPIC -DPIC -o .libs/signalprocessing.o
signalprocessing.cc: In function ‘giac::gen giac::_resample(const giac::gen&, const giac::context*)’:
signalprocessing.cc:637:77: error: assignment of read-only location ‘*(data.SRC_DATA::data_in + ((sizetype)(((long unsigned int)((i * nc) + j)) * 4)))’
             data.data_in[i*nc+j]=_evalf(chdata[j][i],contextptr).DOUBLE_val();

But I know that glpk and nauty are new possible dependencies. As they standard sage packages, may be we should add them to giac's deps in sage?

glpk has been a dependency in the 1.4 series too. I hadn't noticed, seems to build fine with or without but it means sage installations of giac may be inconsistent which each others so I am in favor to just add it - regardless of this ticket.

The nauty dependency is new to me. Looking at configure.in I can see

AC_CHECK_LIB(nauty,main)
AC_CHECK_HEADERS(nauty/naututil.h)

so it is not fatal if it is not there. Which is just as well because that stuff looks for a library and as far as I know the nauty we have only install a bunch of executables, no libraries or headers.

So at this stage do not add nauty - may be we are thinking of the wrong package.

comment:8 Changed 17 months ago by fbissey

nauty 2.6.7 has libraries. We are at 2.6.1 I think.

comment:9 follow-up: Changed 17 months ago by arojas

Plain upstream nauty doesn't compile shared libraries. It is a (huge) Debian specific patch, also used in Fedora.

comment:10 in reply to: ↑ 9 Changed 17 months ago by fbissey

Replying to arojas:

Plain upstream nauty doesn't compile shared libraries. It is a (huge) Debian specific patch, also used in Fedora.

The Gentoo maintainer has adopted that patch too for 2.6.7 that fooled me.

comment:11 Changed 16 months ago by dimpase

There are still (easy) patches needed to build with clang 6.

Any idea about what would be the best way to get them in?

comment:12 Changed 16 months ago by slelievre

One way would be to suggest these patches on the XCas "bugs" forum: https://xcas.univ-grenoble-alpes.fr/forum/viewforum.php?f=3&sid=c49dc6cf44516f78a1ef24e838c65904

comment:13 follow-up: Changed 16 months ago by frederichan

NB: I can post on this forum for you if you don't have an account or if it is long to answer.

Changed 16 months ago by dimpase

patch needed for giac to build with clang 6.0.1 (possibly incomplete)

comment:14 in reply to: ↑ 13 Changed 16 months ago by dimpase

Replying to frederichan:

NB: I can post on this forum for you if you don't have an account or if it is long to answer.

I requested an account on the forum at least once, to no avail. Anyhow, I just posted the patch here as an attachment.

comment:16 follow-up: Changed 16 months ago by dimpase

Another bug in giac - it does not work with newer versions of libcurl, which don't have curl/curlbuild.h header, see curl's [commit](https://github.com/curl/curl/commit/73a2fcea0b4adea6ba342cd7ed1149782c214ae3)

So since curl version 7.55 or so one needs to use curl/system.h instead.

Could you also report this on giac list?

comment:17 in reply to: ↑ 16 Changed 16 months ago by fbissey

Replying to dimpase:

Another bug in giac - it does not work with newer versions of libcurl, which don't have curl/curlbuild.h header, see curl's [commit](https://github.com/curl/curl/commit/73a2fcea0b4adea6ba342cd7ed1149782c214ae3)

So since curl version 7.55 or so one needs to use curl/system.h instead.

Could you also report this on giac list?

We've know this one for a while. It was present in the last 1.4 releases. In distro we just removed the include line following arch's lead (I believe it originated in arch - correct me if it has prior history).

comment:18 follow-up: Changed 16 months ago by frederichan

curlbuild.h is reported there: https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2180

by the way, was the clang problem a warning or does the compilation stop?

comment:19 in reply to: ↑ 18 Changed 16 months ago by dimpase

Replying to frederichan:

curlbuild.h is reported there: https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2180

by the way, was the clang problem a warning or does the compilation stop?

I only reported errors. There are surely lots of warnings too, e.g. the one about register keyword being ignored and deprecated in C++11, and that it will be an error in C++17 standard.

As a matter of fact I am trying to get giac built on FreeBSD 12.0, and I am not yet there.

comment:20 Changed 16 months ago by dimpase

  • Milestone changed from sage-wishlist to sage-8.5
  • Type changed from PLEASE CHANGE to defect

comment:21 Changed 16 months ago by dimpase

One further patch that was needed for clang 6/freebsd 12.0 is as follows:

--- a/src/misc.h
+++ b/src/misc.h
@@ -23,6 +23,7 @@
 #include "gen.h"
 #include "unary.h"
 #include "symbolic.h"
+#include <sys/time.h>
 
 #ifndef NO_NAMESPACE_GIAC
 namespace giac {

without it there are errors related to a forward declaration of giac::timespec, as follows:

In file included from misc.cc:8744:
In file included from /usr/local/include/curl/curl.h:87:
/usr/include/sys/time.h:267:25: error: variable has incomplete type 'struct timespec'
tstosbt(struct timespec _ts)
                        ^
/usr/include/sys/socket.h:676:8: note: forward declaration of 'giac::timespec'
struct timespec;
       ^
Last edited 16 months ago by dimpase (previous) (diff)

comment:22 Changed 16 months ago by dimpase

OK, I can post to the giac forum now...

comment:23 Changed 15 months ago by dimpase

the giac unstable version (1.5.0-11 (?)) of 18/10/18 builds on clang 6.0.1 out of the box (there is now an issue with doc/el, which seems to be broken, and the need to have hevea installed).

comment:24 Changed 15 months ago by fbissey

I never saw that one but I see 1.5.0-17 from 2018-11-20. I will give it a go later.

comment:25 Changed 15 months ago by fbissey

$ grep -r curlbuild src/*
src/giac/misc.cc:  //#include <curl/curlbuild.h>
src/misc.cc:  //#include <curl/curlbuild.h>

So the curl issue has been dealt with. clang is going mad spitting that "register" is deprecated and is incompatible with C++17.

comment:26 Changed 15 months ago by gh-symphorien

When building sage with giac 1.5.0-21 I get this test failure:

File "/nix/store/kb25pb31a6i47sjm5nsjgii7n7jpilgb-sage-src-8.4/src/sage/interfaces/giac.py", line 619, in sage.interfaces.giac.Giac.eval
Failed example:
    giac(s)
Expected:
    (x)->{
    x+1;
    x+2;
    }
Got:
    (x)->[x+1,x+2]
**********************************************************************
1 item had failures:
   1 of   6 in sage.interfaces.giac.Giac.eval

Upstream said wontfix: https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2221

comment:27 Changed 15 months ago by dimpase

We'd just change this doctest, such things happen often with many packages

comment:28 Changed 15 months ago by fbissey

It is already present with the latest 1.4.x. It is just formatting, nothing serious.

Changed 15 months ago by gh-symphorien

comment:29 Changed 15 months ago by gh-symphorien

Ok. Then with the attached patch I can build sage with giac 1.5.0-21.

comment:30 follow-up: Changed 15 months ago by rws

Attachment giac-1.5.0-3.clang601.patch​ added

patch needed for giac to build with clang 6.0.1 (possibly incomplete)

BTW this is also needed for the current giac-1.4.9.45.p4 and clang++-6/7 because:

solve.cc:5751:23: error: non-constant-expression cannot be narrowed from type 'int' to 'short' in initializer list [-Wc++11-narrowing]
      order_t order_={order,lexvars};
                      ^~~~~
solve.cc:5751:23: note: insert an explicit cast to silence this issue
      order_t order_={order,lexvars};
                      ^~~~~
                      static_cast<short>( )
solve.cc:5751:29: error: non-constant-expression cannot be narrowed from type 'int' to 'unsigned char' in initializer list [-Wc++11-narrowing]
      order_t order_={order,lexvars};
                            ^~~~~~~
solve.cc:5751:29: note: insert an explicit cast to silence this issue
      order_t order_={order,lexvars};
                            ^~~~~~~
                            static_cast<unsigned char>( )
solve.cc:6962:21: error: non-constant-expression cannot be narrowed from type 'int' to 'short' in initializer list [-Wc++11-narrowing]
    order_t order_={order.val,0};
                    ^~~~~~~~~
solve.cc:6962:21: note: insert an explicit cast to silence this issue
    order_t order_={order.val,0};
                    ^~~~~~~~~
                    static_cast<short>( )

comment:31 in reply to: ↑ 30 Changed 15 months ago by dimpase

Replying to rws:

Attachment giac-1.5.0-3.clang601.patch​ added

patch needed for giac to build with clang 6.0.1 (possibly incomplete)

BTW this is also needed for the current giac-1.4.9.45.p4 and clang++-6/7 because:

solve.cc:5751:23: error: non-constant-expression cannot be narrowed from type 'int' to 'short' in initializer list [-Wc++11-narrowing]
      order_t order_={order,lexvars};
                      ^~~~~
solve.cc:5751:23: note: insert an explicit cast to silence this issue
      order_t order_={order,lexvars};
                      ^~~~~
                      static_cast<short>( )
solve.cc:5751:29: error: non-constant-expression cannot be narrowed from type 'int' to 'unsigned char' in initializer list [-Wc++11-narrowing]
      order_t order_={order,lexvars};
                            ^~~~~~~
solve.cc:5751:29: note: insert an explicit cast to silence this issue
      order_t order_={order,lexvars};
                            ^~~~~~~
                            static_cast<unsigned char>( )
solve.cc:6962:21: error: non-constant-expression cannot be narrowed from type 'int' to 'short' in initializer list [-Wc++11-narrowing]
    order_t order_={order.val,0};
                    ^~~~~~~~~
solve.cc:6962:21: note: insert an explicit cast to silence this issue
    order_t order_={order.val,0};
                    ^~~~~~~~~
                    static_cast<short>( )

does the current https://www-fourier.ujf-grenoble.fr/~parisse/giac/giac_unstable.tgz work for you with new clangs? (this should be giac-1.5.0-21 or even later version)

comment:32 Changed 14 months ago by dimpase

  • Description modified (diff)

should we go forward and upgrade?

comment:33 follow-up: Changed 14 months ago by fbissey

Who says it's stable but why not. Spotted in my log while testing -27, anyone knows when ecm became an automagic dependency (like glpk and friends)? Never mind, I have past logs, it happened in -21 and -19 didn't have it.

Who said it was stable again?

Last edited 14 months ago by fbissey (previous) (diff)

comment:34 in reply to: ↑ 33 Changed 14 months ago by dimpase

Replying to fbissey:

Who says it's stable but why not. Spotted in my log while testing -27, anyone knows when ecm became an automagic dependency (like glpk and friends)? Never mind, I have past logs, it happened in -21 and -19 didn't have it.

Who said it was stable again?

that's one that made it into this particular directory, which I think means "it's not too bad to be released".

comment:35 Changed 14 months ago by fbissey

Right, if someone pushes a branch, I can review it. If you want me to do the branch I can probably squeeze it before Christmas.

comment:36 Changed 14 months ago by chapoton

  • Description modified (diff)
  • Milestone changed from sage-8.5 to sage-8.7

comment:37 Changed 14 months ago by chapoton

  • Branch set to public/giac-1.5.0
  • Commit set to 1caee2941edd46bbc7f2c8c7575099a8b2c84f80

Here is a first tentative of branch. Patches need to be checked. I removed 3 conflicting ones and did not add any new one.


New commits:

1caee29tentative branch for giac 1.5.0

comment:38 Changed 13 months ago by gh-timokau

  • Cc gh-timokau added

comment:39 Changed 13 months ago by dimpase

  • Description modified (diff)

needs an update to the latest version 1.5.0-37

comment:40 Changed 13 months ago by git

  • Commit changed from 1caee2941edd46bbc7f2c8c7575099a8b2c84f80 to bd3c3b11404e593ad077e39b038b2e547e53138e

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

4d45de6Merge branch 'public/giac-1.5.0' of trac.sagemath.org:sage into giacnew
bd3c3b1update giac to 1.5.0-37

comment:41 Changed 13 months ago by dimpase

Now, linking to libz is broken (on Linux). Instead of linking to Sage's libz, it links to the system one, getting

$ ldd local/bin/giac | grep libz
local/bin/giac: /lib/x86_64-linux-gnu/libz.so.1: version `ZLIB_1.2.9' not found (required by /home/dimpase/sage/local/lib/libpng16.so.16)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f49c3ac8000)

whereas

$ ldd local/lib/libpng16.so
        linux-vdso.so.1 (0x00007ffe74fe5000)
        libz.so.1 => /home/dimpase/sage/local/lib/libz.so.1 (0x00007effe8642000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effe833e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effe7f9f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007effe8a9f000)

comment:42 Changed 13 months ago by fbissey

Fact, libpng is only used by giac when the fltk interface is built. Otherwise libpng is not used at all as revealed by using -Wl,--as-needed in LDFLAGS. If we disable the gui (fltk) we can disable png safely.

comment:43 Changed 13 months ago by dimpase

I'm currently trying to build it with --enable-png=no. It seems to work better.

comment:44 Changed 13 months ago by dimpase

It does not pick up libpng any more, and ldd does not show errors, but the system's libz.so is stil there, from some other dependency:

$ ldd local/bin/giac
        linux-vdso.so.1 (0x00007fff8efa6000)
        libgiac.so.0 => /home/dimpase/sage/local/lib/libgiac.so.0 (0x00007fe5550d4000)
        libntl.so.33 => /home/dimpase/sage/local/lib/libntl.so.33 (0x00007fe554cbd000)
        libpari-gmp.so.6 => /home/dimpase/sage/local/lib/libpari-gmp.so.6 (0x00007fe554210000)
        libreadline.so.6 => /home/dimpase/sage/local/lib/libreadline.so.6 (0x00007fe553fc7000)
        libgsl.so.23 => /home/dimpase/sage/local/lib/libgsl.so.23 (0x00007fe553b45000)
        libgslcblas.so.0 => /home/dimpase/sage/local/lib/libgslcblas.so.0 (0x00007fe553908000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe553700000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe5534e3000)
        libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007fe553263000)
        libglpk.so.40 => /home/dimpase/sage/local/lib/libglpk.so.40 (0x00007fe552f8a000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe552d86000)
        libmpfi.so.0 => /home/dimpase/sage/local/lib/libmpfi.so.0 (0x00007fe552b6f000)
        libmpfr.so.6 => /home/dimpase/sage/local/lib/libmpfr.so.6 (0x00007fe5528f9000)
        libgmp.so.23 => /home/dimpase/sage/local/lib/libgmp.so.23 (0x00007fe552685000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe552303000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe551fff000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe551de8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe551a49000)
        libgf2x.so.1 => /home/dimpase/sage/local/lib/libgf2x.so.1 (0x00007fe551833000)
        libtinfo.so.6 => /home/dimpase/sage/local/lib/libtinfo.so.6 (0x00007fe5515fb000)
        libopenblas.so.0 => /home/dimpase/sage/local/lib/libopenblas.so.0 (0x00007fe550748000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe556a11000)
        libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007fe550522000)
        libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fe550300000)
        librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007fe5500e3000)
        libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007fe54feb7000)
        libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007fe54fca9000)
        libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007fe54fa40000)
        libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x00007fe54f5da000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fe54f38f000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fe54f0b5000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fe54ee82000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fe54ec7e000)
        liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fe54ea6f000)
        libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007fe54e81e000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe54e604000)
        libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fe54e2de000)
        libunistring.so.0 => /usr/lib/x86_64-linux-gnu/libunistring.so.0 (0x00007fe54dfc7000)
        libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fe54dc2e000)
        libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007fe54d9f9000)
        libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007fe54d7c2000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fe54d53f000)
        libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fe54d22f000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fe54d023000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fe54ce1f000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fe54cc08000)
        libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fe54c9ed000)
        libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fe54c7ae000)
        libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fe54c549000)
        libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fe54c315000)
        libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fe54c102000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fe54beee000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fe54bce5000)

comment:45 Changed 13 months ago by fbissey

Ca you do readelf -d to see if it needs directly libz or if it is from somewhere else. Here libglpk brings libz. It is possible that there is a stray -lz somewhere in a makefile.

comment:46 Changed 13 months ago by dimpase

I checked, there is no lz anywhere in the log.

comment:47 Changed 13 months ago by fbissey

So that means someone else is bringing that library or someone has a rpath not properly set.

comment:48 Changed 13 months ago by dimpase

indeed, here is the readelf result (on libgiac, which also has (wrong) libz linked in

$ readelf -d local/lib/libgiac.so.0.0.0

Dynamic section at offset 0x11e0b68 contains 41 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libntl.so.33]
 0x0000000000000001 (NEEDED)             Shared library: [libpari-gmp.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgsl.so.23]
 0x0000000000000001 (NEEDED)             Shared library: [libgslcblas.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libglpk.so.40]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libmpfi.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libmpfr.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgmp.so.23]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x000000000000000e (SONAME)             Library soname: [libgiac.so.0]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/dimpase/sage/local/lib]
 0x000000000000000c (INIT)               0x1a4f38
 0x000000000000000d (FINI)               0xf4b6ec
 0x0000000000000019 (INIT_ARRAY)         0x13b29a8
 0x000000000000001b (INIT_ARRAYSZ)       424 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x13b2b50
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1f0
 0x0000000000000005 (STRTAB)             0x5b4e0
 0x0000000000000006 (SYMTAB)             0x15268
 0x000000000000000a (STRSZ)              617616 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x13e7000
 0x0000000000000002 (PLTRELSZ)           150600 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x1802f0
 0x0000000000000007 (RELA)               0xf80c0
 0x0000000000000008 (RELASZ)             557616 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0xf7f00
 0x000000006fffffff (VERNEEDNUM)         8
 0x000000006ffffff0 (VERSYM)             0xf2170
 0x000000006ffffff9 (RELACOUNT)          19508
 0x0000000000000000 (NULL)               0x0

comment:49 Changed 13 months ago by fbissey

After some thinking libcurl is probably your culprit because you are using the system one and it would be linked to the system's libz.

comment:50 Changed 13 months ago by dimpase

system's libz is linked by system's libcurl, indeed. Any way out?

comment:51 follow-up: Changed 13 months ago by fbissey

Apart from

  • not linking libpng (in this case - since it almost never needed --disable-gui --disable-png)
  • LD_PRELOAD of sage's libz
  • good old (DYLIB)LD_LIBRARY_PATH

I don't think so. Something worthy of inspection in that regard is R on the same system.

comment:52 Changed 13 months ago by dimpase

after

--- a/build/pkgs/giac/spkg-install
+++ b/build/pkgs/giac/spkg-install
@@ -44,7 +44,7 @@ if [ "$UNAME" = "Darwin" ]; then
     DISABLENLS="--disable-nls"
 fi
 
-sdh_configure --disable-gui --disable-ao --disable-lapack "$DISABLENLS"
+sdh_configure --disable-gui --disable-ao --disable-lapack "$DISABLENLS" --enable-png=no
 
 #############################################################
 #   Build

I get just one test failure (due to giac output format change) in ptestlong

sage -t --long --warn-long 44.2 src/sage/interfaces/giac.py
**********************************************************************
File "src/sage/interfaces/giac.py", line 619, in sage.interfaces.giac.Giac.eval
Failed example:
    giac(s)
Expected:
    (x)->{
    x+1;
    x+2;
    }
Got:
    (x)->[x+1,x+2]

I am not 100% sure, but it looks like a good enough indication that everything works as expected. I'll try giac with SAGE_CHECK=yes now.

comment:53 Changed 13 months ago by git

  • Commit changed from bd3c3b11404e593ad077e39b038b2e547e53138e to aac9aab5ba636946c71720ba428656e4e2347737

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

d04a5fddo not link libpng
aac9aabformat change in giac output

comment:54 in reply to: ↑ 51 Changed 13 months ago by dimpase

Replying to fbissey:

Apart from

  • not linking libpng (in this case - since it almost never needed --disable-gui --disable-png)
  • LD_PRELOAD of sage's libz
  • good old (DYLIB)LD_LIBRARY_PATH

I don't think so. Something worthy of inspection in that regard is R on the same system.

libR.so links to Sage's version of libz here. I don't know how this happens.

comment:55 Changed 13 months ago by fbissey

Yes I was thinking that R uses curl, but unlike giac, it uses zlib directly rather than through another library. So sage's zlib is probably loaded before libcurl's one.

comment:56 Changed 13 months ago by dimpase

  • Authors set to Dima Pasechnik
  • Status changed from new to needs_review

well, everything seems to be in order after this change. Reviews?

comment:57 Changed 13 months ago by dimpase

  • Description modified (diff)

comment:58 Changed 13 months ago by fbissey

  • Description modified (diff)
  • Status changed from needs_review to needs_work

I would like --disable-samplerate passed to configure as well. It breaks on some system because the version of samplerate is too new.

comment:59 Changed 13 months ago by git

  • Commit changed from aac9aab5ba636946c71720ba428656e4e2347737 to 5108e2b0bb9f575ec15b237789804541a7ae851c

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

5108e2badded --disable-samplerate

comment:60 Changed 13 months ago by dimpase

  • Status changed from needs_work to needs_review

done.

comment:61 Changed 13 months ago by jdemeyer

  • Status changed from needs_review to needs_work
  1. You're not using spkg-src to create the new tarball, resulting in a huge tarball size.
  1. I'm not convinced that we can remove alloca.patch. It doesn't seem like upstream has applied that.

comment:62 Changed 13 months ago by jdemeyer

Maybe the alloca patch is fine after all. Upstream didn't literally apply our patch, but it's close enough.

comment:63 Changed 13 months ago by git

  • Commit changed from 5108e2b0bb9f575ec15b237789804541a7ae851c to 5986d807456bd69b092c90ff43692b9f72078743

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

5986d80smaller tarball

comment:64 Changed 13 months ago by dimpase

  • Description modified (diff)
  • Status changed from needs_work to needs_review

comment:65 Changed 13 months ago by fbissey

  • Reviewers set to François Bissey, Jeroen Demeyer
  • Status changed from needs_review to positive_review

Let's get on with this one.

comment:66 Changed 13 months ago by vbraun

  • Branch changed from public/giac-1.5.0 to 5986d807456bd69b092c90ff43692b9f72078743
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:67 follow-up: Changed 13 months ago by embray

  • Commit 5986d807456bd69b092c90ff43692b9f72078743 deleted

I just got this change on my Ubuntu 14.04 system and giac does not build:

[giac-1.5.0.37] global.cc: In function 'bool giac::my_isnan(double)':
[giac-1.5.0.37] global.cc:4145:19: error: call of overloaded 'isnan(double&)' is ambiguous
[giac-1.5.0.37]      return isnan(d);
[giac-1.5.0.37]                    ^
[giac-1.5.0.37] global.cc:4145:19: note: candidates are:
[giac-1.5.0.37] In file included from /usr/include/math.h:69:0,
[giac-1.5.0.37]                  from /usr/include/c++/4.8/cmath:44,
[giac-1.5.0.37]                  from first.h:498,
[giac-1.5.0.37]                  from giacPCH.h:7,
[giac-1.5.0.37]                  from global.cc:3:
[giac-1.5.0.37] /usr/include/x86_64-linux-gnu/bits/mathcalls.h:234:12: note: int isnan(double)
[giac-1.5.0.37]  __MATHDECL_1 (int,isnan,, (_Mdouble_ __value)) __attribute__ ((__const__));
[giac-1.5.0.37]             ^
[giac-1.5.0.37] In file included from first.h:498:0,
[giac-1.5.0.37]                  from giacPCH.h:7,
[giac-1.5.0.37]                  from global.cc:3:
[giac-1.5.0.37] /usr/include/c++/4.8/cmath:626:3: note: constexpr bool std::isnan(long double)
[giac-1.5.0.37]    isnan(long double __x)
[giac-1.5.0.37]    ^
[giac-1.5.0.37] /usr/include/c++/4.8/cmath:622:3: note: constexpr bool std::isnan(double)
[giac-1.5.0.37]    isnan(double __x)
[giac-1.5.0.37]    ^
[giac-1.5.0.37] /usr/include/c++/4.8/cmath:618:3: note: constexpr bool std::isnan(float)
[giac-1.5.0.37]    isnan(float __x)
[giac-1.5.0.37]    ^
[giac-1.5.0.37] global.cc: In function 'bool giac::my_isinf(double)':
[giac-1.5.0.37] global.cc:4158:19: error: call of overloaded 'isinf(double&)' is ambiguous
[giac-1.5.0.37]      return isinf(d);
[giac-1.5.0.37]                    ^
[giac-1.5.0.37] global.cc:4158:19: note: candidates are:
[giac-1.5.0.37] In file included from /usr/include/math.h:69:0,
[giac-1.5.0.37]                  from /usr/include/c++/4.8/cmath:44,
[giac-1.5.0.37]                  from first.h:498,
[giac-1.5.0.37]                  from giacPCH.h:7,
[giac-1.5.0.37]                  from global.cc:3:
[giac-1.5.0.37] /usr/include/x86_64-linux-gnu/bits/mathcalls.h:201:12: note: int isinf(double)
[giac-1.5.0.37]  __MATHDECL_1 (int,isinf,, (_Mdouble_ __value)) __attribute__ ((__const__));
[giac-1.5.0.37]             ^
[giac-1.5.0.37] In file included from first.h:498:0,
[giac-1.5.0.37]                  from giacPCH.h:7,
[giac-1.5.0.37]                  from global.cc:3:
[giac-1.5.0.37] /usr/include/c++/4.8/cmath:608:3: note: constexpr bool std::isinf(long double)
[giac-1.5.0.37]    isinf(long double __x)
[giac-1.5.0.37]    ^
[giac-1.5.0.37] /usr/include/c++/4.8/cmath:604:3: note: constexpr bool std::isinf(double)
[giac-1.5.0.37]    isinf(double __x)
[giac-1.5.0.37]    ^
[giac-1.5.0.37] /usr/include/c++/4.8/cmath:600:3: note: constexpr bool std::isinf(float)
[giac-1.5.0.37]    isinf(float __x)
[giac-1.5.0.37]    ^
[giac-1.5.0.37] make[4]: *** [global.lo] Error 1

comment:68 in reply to: ↑ 67 ; follow-up: Changed 13 months ago by dimpase

Replying to embray:

I just got this change on my Ubuntu 14.04 system and giac does not build:

...

[giac-1.5.0.37] /usr/include/c++/4.8/cmath:618:3: note: constexpr bool std::isnan(float)

...

}}}

hmm, blacklist gcc 4.8.* ? With EOL of 14.04 in April 2019, why bother fixing this?

comment:69 Changed 13 months ago by embray

Apparently this may actually be a bug in some older libstdc++ https://stackoverflow.com/a/33770775/982257

comment:70 in reply to: ↑ 68 Changed 13 months ago by embray

Replying to dimpase:

Replying to embray:

I just got this change on my Ubuntu 14.04 system and giac does not build:

...

[giac-1.5.0.37] /usr/include/c++/4.8/cmath:618:3: note: constexpr bool std::isnan(float)

...

}}}

hmm, blacklist gcc 4.8.* ? With EOL of 14.04 in April 2019, why bother fixing this?

It's definitely getting up there. I'll be annoyed if I have to distupgrade this machine, but at the same time it may be inevitable quite soon anyways. Regardless, I've made it this far, and if a simple ::isnan is enough to fix it...

comment:71 Changed 13 months ago by embray

Interestingly, the code where this is coming up is already in a my_isnan function defined in src/global.cc like:

#if defined(FIR_LINUX) || defined(FIR_ANDROID)
    return std::isnan(d);
#else
    return isnan(d);
#endif

where if FIR_LINUX is defined it will do the right thing I think. But I have no idea what this macro FIR_LINUX means, or what FIR means, nor is it at all clear how it gets set.

comment:72 Changed 13 months ago by embray

IMO we should never "upgrade" packages that don't even have publicly accessible source code repositories. It makes it impossible to debug what changed between versions if something goes wrong. Incredible.

comment:73 follow-up: Changed 13 months ago by slelievre

The source code repository of Giac is available as part of the Geogebra one:

comment:74 in reply to: ↑ 73 Changed 12 months ago by embray

Replying to slelievre:

The source code repository of Giac is available as part of the Geogebra one:

For some reason I thought they were just vendoring giac on a version-by-version basis, but it turns out I'm wrong. This seems to actually be the repository for giac. Nice find!~~

Upon closer inspection no, it can't be. It seems like somehow bits of giac are being synced into this repository, but it's not the full source code for giac. So I'm really confused.

Last edited 12 months ago by embray (previous) (diff)

comment:75 follow-up: Changed 12 months ago by embray

I think this might have also broken something on Cygwin. After fixing all the other blocking issues on Cygwin, the tests for sage.interfaces.giac now hang.

comment:76 in reply to: ↑ 75 Changed 12 months ago by embray

Replying to embray:

I think this might have also broken something on Cygwin. After fixing all the other blocking issues on Cygwin, the tests for sage.interfaces.giac now hang.

Well, I tried it a few more times and it worked, so if there is a problem it's not easy to reproduce. At the very least, then, there's nothing to do for now until and unless I can reproduce the problem again. If so, I'll just open a new ticket about it.

comment:77 Changed 12 months ago by embray

For #25822 and #25324 are there specific fixes from upstream that we know of that could easily be applied as patches? I'm wondering if we couldn't partially revert back to the old giac, plus patches for any specific known issues that this was meant to fix, until and unless I can figure out what's going on with #27385.

comment:78 Changed 12 months ago by dimpase

I don't know about any specific patches - it took several iterations of communicating with Giac's author to fix Clang 6.0-specific bugs on giac's forum.

Note: See TracTickets for help on using tickets.