sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.45k stars 481 forks source link

Upgrade to Giac 1.5 #26315

Closed slel closed 5 years ago

slel commented 6 years ago

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

frederichan-IMJPRG commented 6 years ago
comment:1

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

slel commented 6 years ago

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.
slel commented 6 years ago
comment:3

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.

frederichan-IMJPRG commented 6 years ago
comment:4

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

kiwifb commented 6 years ago
comment:5

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.

frederichan-IMJPRG commented 6 years ago
comment:6

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

kiwifb commented 6 years ago
comment:7

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.

kiwifb commented 6 years ago
comment:8

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

antonio-rojas commented 6 years ago
comment:9

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

kiwifb commented 6 years ago
comment:10

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.

dimpase commented 6 years ago
comment:11

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

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

slel commented 6 years ago
comment:12

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

frederichan-IMJPRG commented 6 years ago
comment:13

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

dimpase commented 6 years ago

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

dimpase commented 6 years ago
comment:14

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.

frederichan-IMJPRG commented 6 years ago
comment:15

I have reported it there: https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2176

dimpase commented 6 years ago
comment:16

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?

kiwifb commented 6 years ago
comment:17

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

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

frederichan-IMJPRG commented 6 years ago
comment:18

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?

dimpase commented 6 years ago
comment:19

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.

dimpase commented 6 years ago
comment:21

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;
       ^
dimpase commented 6 years ago
comment:22

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

dimpase commented 5 years ago
comment:23

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

kiwifb commented 5 years ago
comment:24

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

kiwifb commented 5 years ago
comment:25
$ 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.

3a966396-7f39-4ad2-8e5e-0ccdb7f84779 commented 5 years ago
comment:26

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

dimpase commented 5 years ago
comment:27

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

kiwifb commented 5 years ago
comment:28

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

3a966396-7f39-4ad2-8e5e-0ccdb7f84779 commented 5 years ago
comment:29

Attachment: giac-1.5.0.patch.gz

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

rwst commented 5 years ago
comment:30

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>( )
dimpase commented 5 years ago
comment:31

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)

dimpase commented 5 years ago

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
dimpase commented 5 years ago
comment:32

should we go forward and upgrade?

kiwifb commented 5 years ago
comment:33

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?

dimpase commented 5 years ago
comment:34

Replying to @kiwifb:

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

kiwifb commented 5 years ago
comment:35

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.

fchapoton commented 5 years ago

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
fchapoton commented 5 years ago

Branch: public/giac-1.5.0

fchapoton commented 5 years ago
comment:37

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
fchapoton commented 5 years ago

Commit: 1caee29

dimpase commented 5 years ago
comment:39

needs an update to the latest version 1.5.0-37

dimpase commented 5 years ago

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
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 5 years ago

Changed commit from 1caee29 to bd3c3b1

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 5 years ago

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
dimpase commented 5 years ago
comment:41

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)
kiwifb commented 5 years ago
comment:42

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.

dimpase commented 5 years ago
comment:43

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

dimpase commented 5 years ago
comment:44

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)
kiwifb commented 5 years ago
comment:45

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.

dimpase commented 5 years ago
comment:46

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