On 15.01.19 00:57, Knut Petersen wrote:
It's too late now, and I don't know if I have some spare time tomorrow.
[ continued analysis of tools::python build problem on openSuSE Tumbleweed]
Added some configure and compile options to python.py. Good news: strace shows that
python now uses libdb-4.7. Bad news: it still segfaults. Rebuilt it with 'CFLAGS="-g
-O0"', fired up gdb:
/home/gub/NewGub/gub/target/tools/build/python-2.4.5>
LD_LIBRARY_PATH=/home/gub/NewGub/gub/target/tools/build/python-2.4.5:/home/gub/NewGub/gub/target/tools/root
gdb ./python
GNU gdb (GDB; openSUSE Tumbleweed) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./python...done.
(gdb) -E /home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py build
Undefined command: "-E". Try "help".
(gdb) run -E /home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py
build
Starting program:
/home/gub/NewGub/gub/target/tools/build/python-2.4.5/python -E
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py build
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7eec124 in PyInstance_NewRaw (klass=klass@entry=0x7ffff7e78e30,
dict=0x419e00, dict@entry=0x0) at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Objects/classobject.c:551
551 inst->in_dict = dict;
(gdb) bt
#0 0x00007ffff7eec124 in PyInstance_NewRaw
(klass=klass@entry=0x7ffff7e78e30, dict=0x419e00, dict@entry=0x0)
at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Objects/classobject.c:551
#1 0x00007ffff7eec229 in PyInstance_New (klass=0x7ffff7e78e30,
arg=0x7ffff7e66050, kw=0x0) at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Objects/classobject.c:568
#2 0x00007ffff7ee30d0 in PyObject_Call (func=func@entry=0x7ffff7e78e30,
arg=arg@entry=0x7ffff7e66050, kw=kw@entry=0x0)
at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Objects/abstract.c:1795
#3 0x00007ffff7f40e1e in PyEval_CallObjectWithKeywords
(func=0x7ffff7e78e30, arg=arg@entry=0x7ffff7e66050, kw=kw@entry=0x0)
at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Python/ceval.c:3435
#4 0x00007ffff7f401c7 in _PyExc_Init () at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Python/exceptions.c:1827
#5 0x00007ffff7f68ed0 in Py_InitializeEx (install_sigs=1) at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Python/pythonrun.c:207
#6 Py_InitializeEx (install_sigs=1) at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Python/pythonrun.c:134
#7 0x00007ffff7f6e8a4 in Py_Main (argc=4, argv=0x7fffffffda28) at
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Modules/main.c:427
#8 0x00007ffff6c8bfeb in __libc_start_main (main=0x401040 <main>, argc=4,
argv=0x7fffffffda28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized
out>,
stack_end=0x7fffffffda18) at ../csu/libc-start.c:308
#9 0x000000000040107a in _start () at ../sysdeps/x86_64/start.S:120
So ./python almost immediately segfaults during processing of Py_Initialize().
Asked google about 'segfault python-2.4.5/Objects/classobject.c:551'.
1st answer: https://sourceforge.net/p/testlilyissues/issues/5425/ ;-)
So the same problem Federico Bruni hit on Fedora 28 with gcc version 8.1.1 is
present on openSuSE Tumbleweed at with gcc version 8.2.1. The problem is not
present on ubuntu 18, that distribution uses gcc 7.3.
Should this be an incompatibility of gcc 8.* and python 2.4.5?
On openSuSE Tumbleweed there's also gcc-7 (gcc version 7.4.). Let's try to add
'CC=gcc-7' to configure_command.
'bin/gub tools::python' succeeds. All other ::python targets succeed!
Be brave ... try 'make lilypond' ;-)
Results: Building of all *::lilypond targets succeed. But building of
lilypond-test fails.
./target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/lilypond-book/suffix-tely.texi2pdf.log:
/home/gub/NewGub/gub/target/tools/root/usr/bin/texi2dvi: texinfo.tex appears
to be broken.
This may be due to the environment variable TEX set to something
other than (plain) tex, a corrupt texinfo.tex file, or
to tex itself simply not working.
etex: /home/gub/NewGub/gub/target/linux-64/root/usr/lib/libstdc++.so.6:
version `CXXABI_1.3.9' not found (required by etex)
etex: /home/gub/NewGub/gub/target/tools/root/usr/lib/libz.so.1: no version
information available (required by /usr/lib64/libpng16.so.16)
etex: /home/gub/NewGub/gub/target/tools/root/usr/lib/libz.so.1: no version
information available (required by /usr/lib64/libpng16.so.16)
etex: /home/gub/NewGub/gub/target/linux-64/root/usr/lib/libstdc++.so.6:
version `GLIBCXX_3.4.21' not found (required by /usr/lib64/libpoppler.so.79)
/home/gub/NewGub/gub/target/tools/root/usr/bin/texi2dvi: quitting.
Well. Another problem.
@Federico: Is there an easy option to install gcc 7.x on fedora 28? If yes:
What's the name of that compiler?
@everybody: Does anybody volunteer to write a patch to allow python to be compatible with gcc 8? Probably it's easier to tell python's config to look for a gcc-7 (and maybe some other names) if the systems gcc is version 8.x (and to abort with a reasonable error message if no compatible compiler is
found).
Knut
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
