'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

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?

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

So should this be closed as 3rd-party bug, then?

on 2007-02-25 loewis said:

> So should this be closed as 3rd-party bug, then?

that'll be a "roger" (beep).  3rd-party bug is the shortest precise
term. the problem had been discussed several times before. it doesn't
show up with the libncurses.* in the base system. as soon as another
package pulls in the "wrong" dependency, later builds can break.

regards, clemens

on 2007-02-25 loewis said:

> So should this be closed as 3rd-party bug, then?

that'll be a "roger" (beep).  3rd-party bug is the shortest precise
term. the problem had been discussed several times before. it doesn't
show up with the libncurses.* in the base system. as soon as another
package pulls in the "wrong" dependency, later builds can break.

regards, clemens