Closed cyrilbouvier closed 1 year ago
Thanks for the detailed report.
Could you try make -j list-broken-packages
and post its output.
You could also try whether export LD_PRELOAD=/sage-9.8/local/lib/libz.so
makes a difference
Could you try make -j list-broken-packages and post its output.
See sage.bug.centos.log for the output
You could also try whether
export LD_PRELOAD=/sage-9.8/local/lib/libz.so
makes a difference
Running LD_PRELOAD=/sage-9.8/local/lib/libz.so ./sage
works without errors: the message about the 'limited REPL' does not appear anymore, sage.all
seems to be imported (for example, ZZ
exists) and import sage.all
run without errors.
Thanks for the tip, I will use it like that for a while and see if I see encounter other problems.
Even with LD_PRELOAD set up in my environment variables, I encounter a similar problem when trying to install the optional package cryptominisat
: the ./configure script picked up the libz in /lib64/
and the make part ended in an error. Extract from logs/pkgs/cryptominisat-5.8.0.log
...
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.7")
...
g++ (...) /usr/lib64/libz.so (... more libs)
/src/sage-9.8/local/lib/libpng16.so.16: undefined reference to `inflateValidate@ZLIB_1.2.9'
collect2: error: ld returned 1 exit status
So I investigated a little bit more:
I used LD_DEBUG=libs to list all libraries loaded when sage is run, and I use ldd on all of them to see which one had a dependency on libz. Most used the correct path /sage-9.8/src/local/lib
but 7 of them were depending on libz from /lib64/
:
/lib64/libcrypto.so.10
...
libz.so.1 => /lib64/libz.so.1 (0x00007fcc30388000)
...
/lib64/libssl.so.10
...
libz.so.1 => /lib64/libz.so.1 (0x00007f97a1f43000)
...
/sage-9.8/src/sage/symbolic/function.cpython-39-x86_64-linux-gnu.so
...
libz.so.1 => /lib64/libz.so.1 (0x00007f1154513000)
...
/trinity/shared/apps/local/Python/3.9.13/lib/python3.9/lib-dynload/binascii.cpython-39-x86_64-linux-gnu.so
...
libz.so.1 => /lib64/libz.so.1 (0x00007f5754554000)
...
/trinity/shared/apps/local/Python/3.9.13/lib/python3.9/lib-dynload/_hashlib.cpython-39-x86_64-linux-gnu.so
...
libz.so.1 => /lib64/libz.so.1 (0x00007fe32858d000)
...
/trinity/shared/apps/local/Python/3.9.13/lib/python3.9/lib-dynload/_ssl.cpython-39-x86_64-linux-gnu.so
...
libz.so.1 => /lib64/libz.so.1 (0x00007ffbc9616000)
...
/trinity/shared/apps/local/Python/3.9.13/lib/python3.9/lib-dynload/zlib.cpython-39-x86_64-linux-gnu.so
...
libz.so.1 => /lib64/libz.so.1 (0x00007f69a9da9000)
...
It seems that my local version of python (which is used by Sage) depends on libz from /lib64
. Could the problem come from here ?
Also from the 7 libraries, only one is compiled by sage (src/sage/symbolic/function.cpython-39-x86_64-linux-gnu.so). It has a RPATH with the correct value:
$ objdump -x src/sage/symbolic/function.cpython-39-x86_64-linux-gnu.so | grep RPATH
RPATH /sage-9.8/local/lib
but the output of ldd indicates that /lib64/libz.so.1
would be used. Could the problem come from here ?
Thanks a lot for the additional info and investigation.
I agree that the problem is that Python builtin modules depend on the system zlib, which we reject.
(Not sure why our module sage.symbolic.function
is the only Sage-built module with this dependency; this is rather strange.)
In Sage, we already reject system Python (and build our own) if some of its dependency libraries (bzip2 liblzma libffi) are not accepted from the system. It looks like we need to add zlib to this list. That's now #35638.
Is there an existing issue for this?
Did you read the documentation and troubleshoot guide?
Environment
Steps To Reproduce
from a clean Sage 9.8 source directory
./configure make build ./sage sage: import sage.all
Config log
config.log
Package logs
No package failed to install.
Additional Information
The error is visible when trying to run
./sage
:From what I understand from config.log, sage needed to install libz because the one on the machine was not new enough (it did not have function
inflateValidate
as required bybuild/pkgs/zlib/spkg-configure.m4
):It also needed to install libpng (even if it is available on the machine).
The error looks very similar to #31670, but the issue seems to indicate that it was fixed in 9.5.beta8. I try the same steps with sage 9.5 and sage 9.6 and it failed for both (the error message is the same but the failure happens directly when
./sage
is run, without the need to doimport all
)Here are some extract of objdump of the different libraries: