fedora-34-standard: eclib, singular, ipykernel build failures with system ntl, zeromq

[mkoeppe]

from https://groups.google.com/g/sage-release/c/6WjKQt_e_B8/m/dpx1qILOCwAJ (for 9.3.rc2):

9.3.beta8> fedora-34-standard:
9.3.beta8> [eclib-20190909] /usr/bin/ld: /usr/lib64/libntl.so: undefined reference to `std::__exception_ptr::exception_ptr::_M_release()@CXXABI_1.3.13'

fedora-34-standard eclib problem is unchanged in 9.3.rc2, and also issues with ntl show up in singular

See also: https://groups.google.com/g/sage-release/c/PAeKAGNJIJA/m/Rrncqdp7AQAJ

CC: @dimpase @jamesjer @kiwifb @enriqueartal @orlitzky @malb

Component: porting

Author: Matthias Koeppe

Branch: 3197044

Reviewer: Volker Braun

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

[mkoeppe]

Dependencies: #29703

[mkoeppe]

comment:3

As noted in #29703, upgrading our gcc spkg to 10.3 does not fix this issue.

So we should probably improve our ntl/spkg-configure.m4 to make sure that it is usable. (Related: #31578, which will also modify ntl/spkg-configure.m4

[mkoeppe]

comment:5

As I wrote in https://groups.google.com/g/sage-release/c/PAeKAGNJIJA/m/guT9UeiYAgAJ, we could just have ntl's spkg-configure.m4 reject system NTL if we reject system gcc.
I'm preparing a patch for this

[mkoeppe]

Branch: u/mkoeppe/fedora_34_standard__eclib__singular_build_failures_with_system_ntl

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

New commits:

887e991

build/pkgs/ntl/spkg-configure.m4: Add depcheck for gcc

[mkoeppe]

Commit: 887e991

[mkoeppe]

comment:8

Also:

  [ipykernel-5.2.1] error installing, exit status 1. End of log file:
  [ipykernel-5.2.1]       File "/sage/local/lib64/python3.9/site-packages/zmq/backend/cython/__init__.py", line 6, in <module>
  [ipykernel-5.2.1]         from . import (constants, error, message, context,
  [ipykernel-5.2.1]     ImportError: /sage/local/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib64/libzmq.so.5)
  [ipykernel-5.2.1]     Building wheel for ipykernel (PEP 517): finished with status 'error'
  [ipykernel-5.2.1]     ERROR: Failed building wheel for ipykernel
  [ipykernel-5.2.1]   Failed to build ipykernel

[sagetrac-git]

Changed commit from 887e991 to 5594edd

[sagetrac-git]

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

5594edd

build/pkgs/zeromq/spkg-configure.m4: Add depcheck for gcc

[mkoeppe]

comment:11

With these changes, make build succeeds.
But building the documentation reveals another error:

[dochtml]   File "sage/matrix/matrix_modn_sparse.pyx", line 1, in init sage.matrix.matrix_modn_sparse (build/cythonized/sage/matrix/matrix_modn_sparse.cpp:17097)
[dochtml]   File "sage/matrix/matrix_integer_sparse.pyx", line 1, in init sage.matrix.matrix_integer_sparse (build/cythonized/sage/matrix/matrix_integer_sparse.cpp:17107)
[dochtml]   File "sage/matrix/matrix_integer_dense.pyx", line 1, in init sage.matrix.matrix_integer_dense (build/cythonized/sage/matrix/matrix_integer_dense.cpp:57743)
[dochtml] ImportError: /sage/local/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib64/libvmaf.so.0)

[sagetrac-git]

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

df4274e

build/pkgs/{freetype,libgd}/spkg-configure.m4: Add depcheck for gcc

[sagetrac-git]

Changed commit from 5594edd to df4274e

[enriqueartal]

comment:13

I found this error while building, I think that --with-system-libgd=no --with-system-brial=no (at least one of them) in ./configure did work.

Replying to @mkoeppe:

With these changes, make build succeeds.
But building the documentation reveals another error:

[dochtml]   File "sage/matrix/matrix_modn_sparse.pyx", line 1, in init sage.matrix.matrix_modn_sparse (build/cythonized/sage/matrix/matrix_modn_sparse.cpp:17097)
[dochtml]   File "sage/matrix/matrix_integer_sparse.pyx", line 1, in init sage.matrix.matrix_integer_sparse (build/cythonized/sage/matrix/matrix_integer_sparse.cpp:17107)
[dochtml]   File "sage/matrix/matrix_integer_dense.pyx", line 1, in init sage.matrix.matrix_integer_dense (build/cythonized/sage/matrix/matrix_integer_dense.cpp:57743)
[dochtml] ImportError: /sage/local/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib64/libvmaf.so.0)

[mkoeppe]

comment:14

I already did the libgd above and just ran into the brial issue too.

[sagetrac-git]

Changed commit from df4274e to 04ca242

[sagetrac-git]

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

04ca242

build/pkgs/brial/spkg-configure.m4: Add depcheck on gcc

[sagetrac-git]

Changed commit from 04ca242 to 2012f7c

[sagetrac-git]

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

2012f7c

build/pkgs/ppl/spkg-configure.m4: Add depcheck on gcc

[sagetrac-git]

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

cedbb31

build/pkgs/fplll/spkg-configure.m4: Add depcheck on gcc

[sagetrac-git]

Changed commit from 2012f7c to cedbb31

[mkoeppe]

comment:18

With this I am running into an fplll build error:

[fplll-5.4.0] libtool: link: g++ -std=c++11 -O2 -g -fPIC -I/sage/local/include/ -Wl,-rpath-link -Wl,/sage/local/lib -Wl,-rpath -Wl,/sage/local/lib -o .libs/fplll main.o  -L/sage/local/lib ./.libs/libfplll.so -lmpfr -lgmp -pthread -Wl,-rpath -Wl,/sage/local/lib
[fplll-5.4.0] libtool: link: g++ -std=c++11 -O2 -g -fPIC -I/sage/local/include/ -Wl,-rpath-link -Wl,/sage/local/lib -Wl,-rpath -Wl,/sage/local/lib -o .libs/latticegen latticegen.o  -L/sage/local/lib ./.libs/libfplll.so -lmpfr -lgmp -pthread -Wl,-rpath -Wl,/sage/local/lib
[fplll-5.4.0] /usr/bin/ld: /usr/lib64/libqd.so.0: undefined reference to `std::__istream_extract(std::istream&, char*, long)@GLIBCXX_3.4.29'
[fplll-5.4.0] collect2: error: ld returned 1 exit status
[fplll-5.4.0] make[6]: *** [Makefile:1119: latticegen] Error 1
[fplll-5.4.0] make[6]: *** Waiting for unfinished jobs....
[fplll-5.4.0] /usr/bin/ld: /usr/lib64/libqd.so.0: undefined reference to `std::__istream_extract(std::istream&, char*, long)@GLIBCXX_3.4.29'
[fplll-5.4.0] collect2: error: ld returned 1 exit status

[mkoeppe]

comment:20

We do not have an spkg for qd -- so we cannot fix this problem with spkg-configure.
Opened #31792 for adding a package for it

[sagetrac-git]

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

3197044

build/pkgs/fplll/spkg-install.in: Configure --without-qd if we use gcc from spkg

[sagetrac-git]

Changed commit from cedbb31 to 3197044

[mkoeppe]

comment:22

This version works for me.
Let's get it into Sage 9.3 please

[dimpase]

comment:23

as #29703 is a dependency with 9.4 milestone, it does not seem to make sense to insist on 9.3 milestone here.

[mkoeppe]

Changed dependencies from #29703 to none

[mkoeppe]

comment:24

I forgot to remove the dependency.

[vbraun]

Reviewer: Volker Braun

[mkoeppe]

comment:26

Thanks!

[vbraun]

Changed branch from u/mkoeppe/fedora_34_standard__eclib__singular_build_failures_with_system_ntl to 3197044

[enriqueartal]

Changed commit from 3197044 to none

[enriqueartal]

comment:28

I am not sure if it is related to this ticket, but I get a persistent error compiling libgd in 9.4.beta0 in Fedora 34:

/usr/bin/ld: /usr/lib64/libvmaf.so.0: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'

For 9.3 ./configure --with-system-zeromq=no --with-system-eclib=no --with-system-flint=no --with-system-flintqs=no --with-system-ntl=no --with-system-libgd=no --with-system-brial=no was ok

[dimpase]

comment:29

Replying to @enriqueartal:

I am not sure if it is related to this ticket, but I get a persistent error compiling libgd in 9.4.beta0 in Fedora 34:

can't you just use the system libgd?

[enriqueartal]

comment:30

Replying to @dimpase:

Replying to @enriqueartal:

I am not sure if it is related to this ticket, but I get a persistent error compiling libgd in 9.4.beta0 in Fedora 34:

can't you just use the system libgd?

Even after ./configure --with-system-libgd=yes it tries to compile libgd-2.3.2

[mkoeppe]

comment:31

libgd is rejected because of g++11. Unfortunately building libgd ourselves appears to create similar issues with other libraries that are (optional) dependencies (not shipped with Sage). The best way to fix this is to fix the remaining issues that block our use of system gcc 11 (#31786). We could also try to fix up our libgd install scripts (see #27901)