Repository navigation
_curses, _curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio 12 #48036
Closed as not planned
Description
| BPO | 3786 |
|---|---|
| Nosy | @loewis, @jcea, @vstinner, @merwok, @serhiy-storchaka |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2008-09-05.09:55:20.360>
labels = ['build']
title = "_curses, _curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio 12"
updated_at = <Date 2017-11-01.17:54:25.874>
user = 'https://bugs.python.org/mschmarck'bugs.python.org fields:
activity = <Date 2017-11-01.17:54:25.874>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2008-09-05.09:55:20.360>
creator = 'mschmarck'
dependencies = []
files = ['14951', '26171']
hgrepos = []
issue_num = 3786
keywords = ['patch']
message_count = 16.0
messages = ['72579', '72581', '72584', '72752', '72768', '72770', '72836', '84920', '93023', '148522', '149005', '149009', '164119', '164875', '164905', '305387']
nosy_count = 9.0
nosy_names = ['loewis', 'jcea', 'vstinner', 'enchanter', 'eric.araujo', 'mschmarck', 'iandekit', 'serhiy.storchaka', 'Justin.Venus']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue3786'
versions = ['Python 3.2', 'Python 3.3']
Activity
mschmarck commentedon Sep 5, 2008
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
pitrou commentedon Sep 5, 2008
As for the multiprocessing problem, it has been fixed recently on trunk.
Can you give it a try?
mschmarck commentedon Sep 5, 2008
Yes, the multiprocessing problem has been fixed by the patch in bpo-3110.
loewis commentedon Sep 7, 2008
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)
mschmarck commentedon Sep 8, 2008
I filed that as a bug against Python 2.6, because in 2.5.2, the curses
modules could be built just fine.
loewis commentedon Sep 8, 2008
So would you like to work on a patch?
mschmarck commentedon Sep 9, 2008
Yes, I would _like_ to do that, but I fear that I lack the necessary
skills...
enchanter commentedon Mar 31, 2009
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.
iandekit commentedon Sep 23, 2009
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.
vstinner commentedon Nov 28, 2011
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 bpo-7384.
vstinner commentedon Dec 8, 2011
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.
vstinner commentedon Dec 8, 2011
I opened the issue bpo-13552 to list all curses issues on OpenIndiana.
10 remaining items
AA-Turner commentedon Jun 7, 2022
Solaris isn't a PEP-11 supported platform, I might suggest closing this issue.
A
vstinner commentedon Jun 7, 2022
There is @kulikjak who is interested in improving Solaris support in Python. If we close all Solaris issues, maybe it would be useful to add an
OS-solarislabel first. So if someone else wants to dig into old closed (rejected) Solaris issues, there is an easy way to list all of them.merwok commentedon Jun 7, 2022
A meta-ticket or project board could be better than a label!
vstinner commentedon Jun 7, 2022
I would prefer to not create a project if the OS is not supported by PEP 11. The purpose of PEP 11 is to reduce the maintenance burden. Adding a project increases the maintenance burden: who maintains the project? what should people do with this project?
kulikjak commentedon Jun 7, 2022
Oh, I didn't know about this issue. I recently created #91964 to fix this/similar issue.
As for listing all the issues, all of those I created have Solaris in their name so searching from them should be simple enough (at least those created by me).
Closing this issue seems reasonable - it's filed against fairly old runtime, and we are not using Sun/Solaris Studio to compile Python for some time and AFAIK neither do other Solaris distributions.
As for other PRs filed against Solaris, Is there something I can do to help with them being reviewed / merged? Would it e.g., help if those were reviewed by people from other Solarises (I believe I know somebody from both Illumos and OmniOS)? I am happy to help with whatever is necessary to get them merged.
AA-Turner commentedon Jun 7, 2022
Closing per Jakub's rationale.
I agree with Victor -- I'm not searching activley for Solaris issues to close them, but given the update to PEP 11 it would be useful to know what the rules of engagement are for unsupported platforms.
Given anyone can create a project on their own fork and add issues, perhaps @kulikjak could create one on an offical Solaris / Oracle fork of CPython to track solaris related issues?
A
kulikjak commentedon Jun 7, 2022
Well, I guess that's possible, but do you think that anybody except for me would realistically look there for Solaris related issues? How would that work?
jcea commentedon Jun 8, 2022
I am interested in Python working in Solaris/Illumos platforms too.