[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gub: I can now completely build lilypond

From: Knut Petersen
Subject: Re: gub: I can now completely build lilypond
Date: Tue, 15 Jan 2019 14:05:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3

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 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:

 gdb ./python
   GNU gdb (GDB; openSUSE Tumbleweed) 8.2
   Copyright (C) 2018 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later <>
   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:
   Find the GDB manual and other documentation resources online at:

   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/ build
   Undefined command: "-E".  Try "help".
   (gdb) run -E /home/gub/NewGub/gub/target/tools/src/python-2.4.5/ 
   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/ build
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib64/".

   Program received signal SIGSEGV, Segmentation fault.
   0x00007ffff7eec124 in PyInstance_NewRaw (address@hidden, dict=0x419e00, 
address@hidden) at 
   551             inst->in_dict = dict;
   (gdb) bt
   #0  0x00007ffff7eec124 in PyInstance_NewRaw (address@hidden, dict=0x419e00, 
   #1  0x00007ffff7eec229 in PyInstance_New (klass=0x7ffff7e78e30, 
arg=0x7ffff7e66050, kw=0x0) at 
   #2  0x00007ffff7ee30d0 in PyObject_Call (address@hidden, address@hidden, 
   #3  0x00007ffff7f40e1e in PyEval_CallObjectWithKeywords 
(func=0x7ffff7e78e30, address@hidden, address@hidden)
   #4  0x00007ffff7f401c7 in _PyExc_Init () at 
   #5  0x00007ffff7f68ed0 in Py_InitializeEx (install_sigs=1) at 
   #6  Py_InitializeEx (install_sigs=1) at 
   #7  0x00007ffff7f6e8a4 in Py_Main (argc=4, argv=0x7fffffffda28) at 
   #8  0x00007ffff6c8bfeb in __libc_start_main (main=0x401040 <main>, argc=4, 
argv=0x7fffffffda28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized 
        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: ;-)

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.


   /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/ 
version `CXXABI_1.3.9' not found (required by etex)
   etex: /home/gub/NewGub/gub/target/tools/root/usr/lib/ no version 
information available (required by /usr/lib64/
   etex: /home/gub/NewGub/gub/target/tools/root/usr/lib/ no version 
information available (required by /usr/lib64/
   etex: /home/gub/NewGub/gub/target/linux-64/root/usr/lib/ 
version `GLIBCXX_3.4.21' not found (required by /usr/lib64/
   /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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]