[ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension doesn't build

Sun Feb 25 19:20:42 CET 2007

Bugs item #1668133, was opened at 2007-02-25 01:03
Message generated for change (Comment added) made by inow
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1

regards, clemens

----------------------------------------------------------------------

>Comment By: clemens fischer (inow)
Date: 2007-02-25 18:20

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 perky writes:

> The ncurses problem is already known and proven as a
> problem of FreeBSD.  And its ports have a workaround
> applied. (-D__wchar_t=wchar_t as you used.)

it may well be a problem of the port that the CFLAGS setting including
this define doesn't cary over into the built.

> The nis compilation error can be raised when your base system was
> built with NO_NIS=yes option.  But build process shouldn't segfault
> even after nis warning.

i noticed that the ports Makefile checks for the existance of
usr/bin/ypcat to decide if NIS support should be included.  i rebuilt
the fbsd world numerous times after the initial install from CD.  NIS
support is disabled on the machine in question, but the yp-programs were
never removed.  after deleting them, the NIS extension still gets built,
but the process doesn't segfault anymore.  the warnings do persist,
though.

> So, can you provide a backtrace of the core dumped for more
> investigation?

for this i would have to have a debug version of the fbsd base systems
gcc, as this is the program segfaulting.  this isn't feasable ATM.

i got another email from Rong-En Fan responding to my freebsd problem
report (1).  he advises to try building python24 after deleting the
development version of ncurses.  i just tried this:  it is the
workaround needed to make python-2.4.4 on fbsd-6.2.

thanks Rong-En Fan and perky!

regards, clemens

(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=109505

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2007-02-25 01:49

Message:
Logged In: YES 
user_id=55188
Originator: NO

The ncurses problem is already known and proven as a problem of FreeBSD. 
And its ports have a workaround applied. (-D__wchar_t=wchar_t as you
used.)

The nis compilation error can be raised when your base system was built
with NO_NIS=yes option.  But build process shouldn't segfault even after
nis warning.

So, can you provide a backtrace of the core dumped for more investigation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470