Closed slel closed 5 years ago
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
Description changed:
---
+++
@@ -3,7 +3,8 @@
A preliminary version "1.5.0 unstable" is available for testing:
- [announcement on Giac / Xcas forum](https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=8&t=2134)
-- [source tarball for giac-1.5.0](https://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.5.0.tar.gz)
+- [source tarball for giac-1.5](https://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/) (take latest giac-1.5.x-y).
+- [README about source tarballs for Giac and their version numbering](http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/README)
This upgrade should solve #25822 and #25324 since the issues reported there are fixed upstream.
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.
From 21 sep I can now see a 1.5.0-3 version:
http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.5.0-3.tar.gz
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.
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
Replying to @frederichan-IMJPRG:
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.
nauty 2.6.7 has libraries. We are at 2.6.1 I think.
Plain upstream nauty doesn't compile shared libraries. It is a (huge) Debian specific patch, also used in Fedora.
Replying to @antonio-rojas:
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.
There are still (easy) patches needed to build with clang 6.
Any idea about what would be the best way to get them in?
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
NB: I can post on this forum for you if you don't have an account or if it is long to answer.
patch needed for giac to build with clang 6.0.1 (possibly incomplete)
Attachment: giac-1.5.0-3.clang601.patch.gz
Replying to @frederichan-IMJPRG:
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.
I have reported it there: https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2176
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
So since curl version 7.55 or so one needs to use curl/system.h
instead.
Could you also report this on giac list?
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 commitSo 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).
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?
Replying to @frederichan-IMJPRG:
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.
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;
^
OK, I can post to the giac forum now...
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).
I never saw that one but I see 1.5.0-17 from 2018-11-20. I will give it a go later.
$ 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.
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
We'd just change this doctest, such things happen often with many packages
It is already present with the latest 1.4.x. It is just formatting, nothing serious.
Attachment: giac-1.5.0.patch.gz
Ok. Then with the attached patch I can build sage with giac 1.5.0-21.
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>( )
Replying to @rwst:
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)
Description changed:
---
+++
@@ -9,3 +9,7 @@
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
+
+tarball: https://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.5.0-27.tar.gz
should we go forward and upgrade?
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?
Replying to @kiwifb:
Who says it's stable but why not. Spotted in my log while testing
-27
, anyone knows whenecm
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".
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.
Description changed:
---
+++
@@ -12,4 +12,4 @@
I suppose we finally have stable 1.5.0, here
-tarball: https://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.5.0-27.tar.gz
+tarball: https://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.5.0-29.tar.gz
Branch: public/giac-1.5.0
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:
1caee29 | tentative branch for giac 1.5.0 |
needs an update to the latest version 1.5.0-37
Description changed:
---
+++
@@ -12,4 +12,4 @@
I suppose we finally have stable 1.5.0, here
-tarball: https://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.5.0-29.tar.gz
+tarball: https://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.5.0-37.tar.gz
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)
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.
I'm currently trying to build it with --enable-png=no
. It seems to work better.
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)
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.
I checked, there is no lz
anywhere in the log.
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
CC: @antonio-rojas @kiwifb @frederichan-IMJPRG @infinity0 @saraedum @tobihan @timokau
Component: packages: standard
Keywords: upgrade, giac
Author: Dima Pasechnik
Branch:
5986d80
Reviewer: François Bissey, Jeroen Demeyer
Issue created by migration from https://trac.sagemath.org/ticket/26315