[issue16902] Add OSS module support for Solaris
Tim Mooney added the comment: Sooo It's been 3 years. Brian's patch has bit-rotted a bit, but it's easy to update for recent Python. What are the hold-ups to getting this applied? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
Tim Mooney added the comment: I just tried Python 2.7.6 on x86_64-pc-openindiana151a9. The core issue is still present. It's not currently causing a build failure, but only because OpenIndiana 151a9 and Python are using the exact same version of Expat, so the headers that python's build process is mistakenly including from the operating system match the code that it's compiling internally. My comment in msg97311 on 2010-01-06 is still valid. If Python's build process is going to use internal expat, then it better ensure that the compilation flags it needs for that (including the -I) comes before the standard CFLAGS CPPFLAGS. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16902] Add OSS module support for Solaris
Tim Mooney added the comment: For what it's worth, I've been using a patch nearly identical to this one with python 2.6.x and 2.7.x with good success, and in my case it was under Solaris 10 with the no-cost oss package from 4Front. I now have a new workstation and I've installed OpenIndiana (one of the OpenSolaris derivatives) on it, so I've had to revisit my patch slightly to get it to work with Python 2.7.5. It causes no real harm to attempt to build ossaudiodev even on earlier Solaris platforms that don't have the package installed. With Brian's patch or mine, the build reports that it expected to build ossaudiodev but that build failed. There are other modules that setup.py expects to have work on Solaris that do not, so this is not the first instance of trying something only to have it gracefully fail. It's really no different from what's being done with linux -- setup.py attempts to build ossaudiodev for all Linux distributions, even though some of them have ripped out support for OSS, in favor of ALSA or Pulse. I would agree that using individual ifdef's for each define is useful; it appears that the oss package from 4Front provides more of the defines than the modified Boomer OSS headers that are part of the OpenSolaris derivatives. My recommendation would be that Brian's patch or something like it be included as a bug fix in any releases of Python, not as just a new feature in the latest release. -- nosy: +enchanter ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
Tim Mooney enchan...@users.sourceforge.net added the comment: This still happens in 2.6.3 and 2.6.4 so I spent some time looking at it. It's happening because of a combination of issues, but ultimately it's because python's build isn't making certain that it's including its private copy of expat.h and expat_external.h. Basically, this -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/local/src/RPM/BUILD/Python-2.6.4/./Modules/expat should *precede* CFLAGS, rather than coming after it. To reproduce: - install expat 2.0.1 under /usr/local or /opt (or any prefix other than just /usr) - include -I$prefix/include in CFLAGS when configuring Python - make This results in the special includes for python's local copy of the expat sources being *after* the -I/usr/local/include on the command line, so the copy of expat.h and expat_external.h in /usr/local/include are found first, and that causes the link failure when generating pyexpat.so. Note that it's not just as simple as not including -I/usr/local/include in CFLAGS, because there may be other locally-installed packages that python should be finding to build other modules. The real fix is for Python's build machinery to make certain that the special includes for Python's private expat sources precede CFLAGS. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
New submission from Tim Mooney enchan...@users.sourceforge.net: I've built Python 2.6.1 and Python 2.6.2 on x86_64-sun-solaris2.10 using the Sun Workshop Express (200903) toolchain. I'm building in 64 bit mode. Most stuff builds just fine (even warnings are rare), but pyexpat fails to link with this error: building 'pyexpat' extension creating build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I. -I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -I/usr/local/include -I/local/src/RPM/BUILD/Python-2.6.2/Include -I/local/src/RPM/BUILD/Python-2.6.2 -c /local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.c -o build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.o /local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.c, line 1574: warning: assignment type mismatch: pointer to void = pointer to function(pointer to void, pointer to const ch ar, int) returning void cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I. -I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -I/usr/local/include -I/local/src/RPM/BUILD/Python-2.6.2/Include -I/local/src/RPM/BUILD/Python-2.6.2 -c /local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.c -o build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.o cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I. -I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -I/usr/local/include -I/local/src/RPM/BUILD/Python-2.6.2/Include -I/local/src/RPM/BUILD/Python-2.6.2 -c /local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.c -o build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.o cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I. -I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include -I/local/include -I/local/ gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -I/usr/local/include -I/local/src/RPM/BUILD/Python-2.6.2/Include -I/local/src/RPM/BUILD/Python-2.6.2 -c /local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.c -o build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.o cc -xtarget=native -m64 -xarch=native -G -L/local/lib/64 -L/local/gnu/lib/64 -L/local/BerkeleyDB/lib/64 -L/local/openssl/lib/64 -L/local/lib/64 -L/local/gnu/lib/64 -L/local/BerkeleyDB/lib/64 -L/local/openssl/lib/64 -DNDEBUG -Xa -xO4 -xstrconst -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include -I. -IInclude -I./Include -I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.o build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.o build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.o build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.o -L/local/lib -L/local/lib/64 -L/local/gnu/lib/64 -L/local/BerkeleyDB/lib/64 -L/local/openssl/lib/64 -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.6/pyexpat.so *** WARNING: renaming pyexpat since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-i86pc-2.6/pyexpat.so: symbol XML_SetCharacterDataHandler: referenced symbol not found I never tried any of the 2.5.x Python builds, but I can tell you that I built several versions in the 2.4.x series, and none of those versions had problems compiling or linking pyexpat. I do have expat 2.0.1 (also built with the Sun compiler in 64 bit mode
[issue3786] _curses, _curses_panel _multiprocessing can't be build in 2.6b3 w/ SunStudio 12
Tim Mooney enchan...@users.sourceforge.net added the comment: 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. -- nosy: +enchanter ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1306248] Add 64-bit Solaris 9 build instructions to README
Tim Mooney [EMAIL PROTECTED] added the comment: I agree with Terry's comment -- Python's build machinery for multi-abi systems is suboptimal, but documenting some methods that work for some people would at least help. -- nosy: +enchanter _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1306248 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
