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 22:25 Message: Logged In: YES user_id=71514 Originator: YES 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 ---------------------------------------------------------------------- Comment By: clemens fischer (inow) Date: 2007-02-25 22:25 Message: Logged In: YES user_id=71514 Originator: YES 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 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2007-02-25 21:57 Message: Logged In: YES user_id=21627 Originator: NO So should this be closed as 3rd-party bug, then? ---------------------------------------------------------------------- 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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
