homepage

I'm trying to compile Python 2.6b3 using Sun Studio 12 on a Solaris 10
sparc system. It fails.
[...]
*** WARNING: renaming "_curses" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-sun4u-2.6/_curses.so: symbol wchgat: referenced
symbol not found
[...]
*** WARNING: renaming "_curses_panel" since importing it failed: No
module named _curses
[...]
"/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c",
line 253: undefined symbol: SEM_VALUE_MAX
[...]
--($ ~/Source/Python-2.6b3)-- /opt/SUNWspro/bin/version
Machine hardware: sun4u
OS version: 5.10
Processor type: sparc
Hardware: SUNW,Sun-Fire-480R
The following components are installed on your system:
Sun Studio 12
 Sun Studio 12 C Compiler
 Sun Studio 12 C++ Compiler
 Sun Studio 12 Tools.h++ 7.1
 Sun Studio 12 C++ Standard 64-bit Class Library
 Sun Studio 12 Garbage Collector 
 Sun Studio 12 Fortran 95 
 Sun Studio 12 Debugging Tools (including dbx)
 Sun Studio 12 IDE
 Sun Studio 12 Debugger GUI
 Sun Studio 12 Performance Analyzer (including collect, ...)
 Sun Studio 12 X-Designer 
 Sun Studio 12 VIM editor
 Sun Studio 12 XEmacs editor
 Sun Studio 12 Performance Library 
 Sun Studio 12 LockLint
 Sun Studio 12 Building Software (including dmake)
 Sun Studio 12 Documentation Set
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
SunOS_sparc Patch 124867-01 2007年07月12日
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9
SunOS_sparc Patch 124863-01 2007年07月25日
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95
8.3 SunOS_sparc Patch 127000-01 2007年07月18日
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx
Debugger 7.6 SunOS_sparc Patch 124872-01 2007年07月12日
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun
Analyzer 7.6 SunOS_sparc Patch 126995-01 2007年07月17日
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun
Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007年07月19日
--($ ~/Source/Python-2.6b3)-- CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007年07月25日
--($ ~/Source/Python-2.6b3)-- cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007年07月12日
usage: cc [ options] files. Use 'cc -flags' for details
--($ ~/Source/Python-2.6b3)-- gmake
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building '_curses' extension
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.6b3/./Include
-I/export/home/webservd/.software/Python-2.6b3/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.6b3/Include
-I/export/home/webservd/Source/Python-2.6b3 -c
/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.c -o
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.c",
line 708: warning: implicit function declaration: mvwchgat
"/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.c",
line 712: warning: implicit function declaration: wchgat
cc -G
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.o
-L/export/home/webservd/.software/Python-2.6b3/lib -L/usr/local/lib
-lcurses -ltermcap -lpython2.6 -o
build/lib.solaris-2.10-sun4u-2.6/_curses.so
*** WARNING: renaming "_curses" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-sun4u-2.6/_curses.so: symbol wchgat: referenced
symbol not found
building '_curses_panel' extension
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.6b3/./Include
-I/export/home/webservd/.software/Python-2.6b3/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.6b3/Include
-I/export/home/webservd/Source/Python-2.6b3 -c
/export/home/webservd/Source/Python-2.6b3/Modules/_curses_panel.c -o
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_curses_panel.o
cc: Warning: illegal option -OPT:Olimit=0
cc -G
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_curses_panel.o
-L/export/home/webservd/.software/Python-2.6b3/lib -L/usr/local/lib
-lpanel -lcurses -ltermcap -lpython2.6 -o
build/lib.solaris-2.10-sun4u-2.6/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No
module named _curses
building '_multiprocessing' extension
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing
-I. -I/export/home/webservd/Source/Python-2.6b3/./Include
-I/export/home/webservd/.software/Python-2.6b3/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.6b3/Include
-I/export/home/webservd/Source/Python-2.6b3 -c
/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c
-o
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c",
line 253: undefined symbol: SEM_VALUE_MAX
cc: acomp failed for
/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c
Failed to find the necessary bits to build these modules:
_bsddb _hashlib _sqlite3 
_ssl _tkinter bsddb185 
gdbm linuxaudiodev ossaudiodev 
readline 
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
Failed to build these modules:
_curses _curses_panel _multiprocessing
running build_scripts

As for the multiprocessing problem, it has been fixed recently on trunk.
Can you give it a try?

Yes, the multiprocessing problem has been fixed by the patch in Issue3110.

Why do you think this is a bug in Python? It sounds like a bug in the
operating system to me.
(actually, it's two bugs - please use separate bug reports in the future:
one is that Solaris doesn't implement wchgat, and the other one that it
doesn't provide SEM_VALUE_MAX. Neither is a fatal bug, though, since
it's just some extension modules that thus fail to build)

I filed that as a bug against Python 2.6, because in 2.5.2, the curses
modules could be built just fine.

> I filed that as a bug against Python 2.6, because in 2.5.2, the curses
> modules could be built just fine.
So would you like to work on a patch?

Yes, I would _like_ to do that, but I fear that I lack the necessary
skills...

Solaris has both traditional System V curses and an XPG4-compatible
curses that does include mvwchgat. The traditional system V curses is
the default, for backward compatibility.
If you want the XPG4 compatible curses, you need to make sure
-I/usr/xpg4/include and -L/usr/xpg4/lib -R/usr/xpg4/lib (or their 64-bit
equivalents) are in CPPFLAGS/CFLAGS/LDFLAGS so that the XPG4 curses is
discovered. See the man page for mvwchgat(3XCURSES) on Solaris for more
info.
The difficulty for Python is that it also tries to build a readline
module, and the libreadline was more than likely linked against the
default system V curses. That means that if you add the -I and -L/-R
flags to get XPG4 curses for all of the Python build, you'll probably
get a link failure or worse when building the readline module.
There are at least two ways around this:
- rebuild readline to use XPG4 curses, and then rebuild every single
 application that links against readline. Then build Python, using
 the -I and -L/-R flags to get XPG4 curses for the entire Python build.
- modify the setup.py for the _curses module so that
 logic is added for Solaris to look for the XPG4 curses only during
 the build of the _curses module.
There is, however, no XPG4 panels library, since panels was not part of
the XPG4 specification. That means that with the appropriate Python
code in setup.py it would be possible to build _curses against XPG4
curses lib, but _curses_panel either couldn't be built or would have to
somehow be linked against the standard (system V) panel library and the
standard curses library.

For those not desiring the use of the chgat function and wishing
to avoid all the fun suggested in the last post (like me), and just
get a _cursesmodule built on Solaris 9 or 10... I enclose a simple patch.

EKIT.patch is not correct: it fails to find mvwchgat() on Linux, whereas the function is present. The test program is not linked to curses nor ncurses.
<< Solaris has both traditional System V curses and an XPG4-compatible
curses that does include mvwchgat. The traditional system V curses is
the default, for backward compatibility.
...
- rebuild readline to use XPG4 curses, and then rebuild every single
 application that links against readline. Then build Python, using
 the -I and -L/-R flags to get XPG4 curses for the entire Python build.
- modify the setup.py for the _curses module so that
 logic is added for Solaris to look for the XPG4 curses only during
 the build of the _curses module. >>
Link _curses module to a different curses library than the library used by readline may lead to crash: see issue #7384.

I hacked setup.py and _cursesmodule.c to use XPG4 curses. It requires many hacks because it lacks functions like getattrs() or getsyx/setsyx, constant like KEY_MIN and KEY_MAX. It looks difficult to use this curses library.

I opened the issue #13552 to list all curses issues on OpenIndiana.

The attached patch allows _curses and _curses_panel to build with the sunpro compiler on Solaris11. The only changes were compiler/linker options in the main setup.py. The interactive curses_test works on my system. I can easily make patches for python2.7 and python3.2 as well.
This patch may also address the issue in bug 13552 as well.

+ # work around for assumption on line 128 of Modules/_cursesmodule.c
Is it impossible to fix the offending code instead of working around it in setup.py?

I am sure that macro object is there for good reason, it just doesn't apply
for Solaris 11.
On Jul 7, 2012 10:34 AM, "Éric Araujo" <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> + # work around for assumption on line 128 of
> Modules/_cursesmodule.c
>
> Is it impossible to fix the offending code instead of working around it in
> setup.py?
>
> ----------
> nosy: +eric.araujo
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3786>
> _______________________________________
>

Issue31919 have made _curses be built on OpenIndiana with the default curses library. I suppose this have fixed this issue on Solaris too.
But configuring _curses to use XPG4 curses is a different issue.