Bugzilla – Bug 7057
ncurses segfaults during compile
Last modified: 2007-04-01 01:47:23 UTC
I've had this happen to me on two different computers/architectures. Same thing happens on both machines. Very wierd. ** Building terminfo database, please wait... Running tic to install /usr/share/terminfo ... You may see messages regarding unknown capabilities, e.g., AX. These are extended terminal capabilities which can be compiled using tic -x Read the INSTALL document before doing this - it can cause problems for older ncurses applications. "../misc/terminfo.src", line 402, col 3, terminal 'ecma+color': unknown capability 'AX' "../misc/terminfo.src", line 2920, col 31, terminal 'xterm-1002': unknown capability 'XM' "../misc/terminfo.src", line 2922, col 31, terminal 'xterm-1003': unknown capability 'XM' "../misc/terminfo.src", line 3640, col 40, terminal 'screen': unknown capability 'G0' "../misc/terminfo.src", line 3661, col 31, terminal 'screen': unknown capability 'E0' "../misc/terminfo.src", line 3661, col 44, terminal 'screen': unknown capability 'S0' "../misc/terminfo.src", line 4594, col 13, terminal 'djgpp204': unknown capability 'AX' 1486 entries written to /usr/share/terminfo ** built new /usr/share/terminfo ** sym-linked /usr/lib/terminfo for compatibility installing std installing stdcrt installing vt100 installing vt300 make[2]: Leaving directory `/usr/src/ncurses-5.4/misc' cd c++ && /usr/bin/make DESTDIR="" install make[2]: Entering directory `/usr/src/ncurses-5.4/c++' /bin/install -c ../lib/libncurses++.a /usr/lib/libncurses++.a installing ./cursesapp.h in /usr/include installing ./cursesf.h in /usr/include installing ./cursesm.h in /usr/include installing ./cursesp.h in /usr/include installing ./cursesw.h in /usr/include installing ./cursslk.h in /usr/include installing etip.h in /usr/include make[2]: Leaving directory `/usr/src/ncurses-5.4/c++' make[1]: Leaving directory `/usr/src/ncurses-5.4' make: *** [ncurses] Segmentation fault make: *** No rule to make target `coreutils', needed by `basesystem'. make: *** No rule to make target `gcc', needed by `basesystem'. make: *** No rule to make target `textutils', needed by `basesystem'. make: *** No rule to make target `termcap', needed by `psmisc'. make: Target `all' not remade because of errors.
*** This bug has been marked as a duplicate of 7029 ***
fix I think is applied in test and devel grimoires... see other bug. erics
I'm not sure how these two bugs relate... Ncurses segfaults for me on two different machines. The make: *** No rule to make target `coreutils', needed by `basesystem'. make: *** No rule to make target `gcc', needed by `basesystem'. make: *** No rule to make target `textutils', needed by `basesystem'. make: *** No rule to make target `termcap', needed by `psmisc'. stuff doesn't cause it to fail, if that's what you're thinking. For some strange reason ncurses segmentation faults during it's install: /bin/install -c ../lib/libncurses++.a /usr/lib/libncurses++.a installing ./cursesapp.h in /usr/include installing ./cursesf.h in /usr/include installing ./cursesm.h in /usr/include installing ./cursesp.h in /usr/include installing ./cursesw.h in /usr/include installing ./cursslk.h in /usr/include installing etip.h in /usr/include make[2]: Leaving directory `/usr/src/ncurses-5.4/c++' make[1]: Leaving directory `/usr/src/ncurses-5.4' make: *** [ncurses] Segmentation fault either that or it's make thats segfaulting. I know its not my computer because it's happening on multiple (3) machines.
David, if you recompile psmisc and then cast ncurses, does it still segfault?
the libs guru needs to be more competent than to copy libraries to fix a simple ./configure problem. If he had taken the time to read the commented lines in BUILD before deleting them he would have seen that your conversion to API2 lost --libdir=/lib which was how the API1 spell solved the problem of making the libs available at boot before /usr was mounted. It's a real shame all the problems in sorcery during his attempts to mislead that team didn't teach him anything, and I can't believe he expected you guys to give him stable grimoire access ! Perhaps the current libs guru should be reassigned to some section that doesn't require common sense, deductive skills or general competence. Of course as I don't use smgl any more and I have my own "grimoire" , whatever you decide is your business, it just seems like the reasons I left are still valid so I took the chance to say "I told you so" Happy SMuGLing
I can't reproduce the segfault, but try if the current spell in test works for you David. Hamish: Eric didn't do the BUILD_API conversion of this spell that lost the --libdir switch and used copying instead, so no need for those remarks.
Arwed, please read bug 7026 (not 7029 which, unfortunately, schabell incorrectly marked this as a duplicate of) and you will see that while schabell wasn't responsible for commenting out all the old ./configure code in BUILD he was the one who removed it and added the rm of the /lib/* still leaving the cp -* line, that caused the problems with API2. It is your choice to allow him to continue making contributions to the grimoire. Honestly appraising his skills based on all the past experiences and only giving him access to some non-volatile section (that won't stop the system from booting and being recoverable by ordinary users) is the right thing to do for the smgl user base. Refusing to hold people accountable for their mistakes and safeguard against futher damage, either because of some good actions in the distant past or because of their high profile is irresponsible towards those users.
Got someone else with the segfault problem to test the fixed spell, seems to work. I integrated it into stable, please check if it works for you when you get back David.
I've had a successful compile of it, so whatever you did works. Testing it on another machine to verify... Success! It works on both machines. wonderful. Even with the negative input from the "doesn't use smgl" user. So I'm gonna close it and call it fixed. Thanks!
well, luckily for you all, being as incompetent as I am... I will just close this bug. erics
reassign to sm-grimoire-bugs