Re: pkg/50490 (ccmake doesn't work)

[bch <brad.harder%gmail.com@localhost>]

The following reply was made to PR pkg/50490; it has been noted by GNATS.

From: bch <brad.harder%gmail.com@localhost>
To: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, wiz%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	pkgsrc-bugs%netbsd.org@localhost
Subject: Re: pkg/50490 (ccmake doesn't work)
Date: Fri, 11 Dec 2015 11:18:31 -0800

 On 12/11/15, Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
 > On Tue, Dec 08, 2015 at 08:20:01AM +0000, bch wrote:
 >>  I updated, and still see it. I'm wondering to myself if it's something
 >> to
 >>  do with the flurry of activity in curses(?) lately.
 >
 > I can't reproduce this with cmake 3.4.1 and NetBSD current. Both the
 > normal optimized and a debug build of ccmake work perfectly fine in
 > cmake itself.
 
 Hrmm... I'm still getting a "blip" on the screen then a failure.
 
 
 
 strathcona$ ldd $(which ccmake )
 /usr/pkg/bin/ccmake:
         -lexecinfo.0 => /usr/lib/libexecinfo.so.0
         -lelf.1 => /usr/lib/libelf.so.1
         -lgcc_s.1 => /usr/lib/libgcc_s.so.1
         -lc.12 => /usr/lib/libc.so.12
         -lform.6 => /usr/pkg/lib/libform.so.6
         -lncurses.6 => /usr/pkg/lib/libncurses.so.6
         -lcurses.7 => /usr/lib/libcurses.so.7
         -lterminfo.1 => /usr/lib/libterminfo.so.1
         -lexpat.2 => /usr/lib/libexpat.so.2
         -lz.1 => /usr/lib/libz.so.1
 ...
 
 strathcona$ cmake --version
 cmake version 3.4.1
 ...
 
 strathcona$ uname -a
 NetBSD strathcona 7.99.24 NetBSD 7.99.24 (GENERIC) #177: Thu Dec 10
 17:23:10 PST 2015
 root@strathcona:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
 
 
 trying w/ fresh zlib (1.2.8) from zlib.net ( http://zlib.net/zlib-1.2.8.tar.gz )
 
 
 strathcona$ ccmake .
 [screen flashes, back to shell prompt]
 
 
 I've done this in a fresh account to attempt to make sure there are
 not any stray configuration files that might affect this (I once had
 an editline configuration mistake that was hard to track to its
 source), but still no luck. The issue is new(ish) to me (last few
 weeks). I've used CMake (ccmake) extensively and don't recall seeing
 this behavior before.
 
 
 -bch
 
 > Joerg
 >