Re: python 6 compilation failure on RHEL
Cameron Simpson c...@zip.com.au writes: My personal habit to to build with (adjust to match): --prefix=/usr/local/python-2.6.4 and put some symlinks in /usr/local/bin afterwards (python2.6, etc). There's actually a program for that, it's called stow. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On 8/20/2012 9:34 PM John Nagle said... After a thread of clueless replies, s/clueless/unread Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On Tue, Aug 21, 2012 at 12:34 AM, John Nagle na...@animats.com wrote: After a thread of clueless replies, it's clear that nobody responding actually read the build log. Here's the problem: The very first reply, Emile's, pointed out that these were optional modules, and that python did, in fact build successfully. Failed to find the necessary bits to build these modules: bsddb185 dl imageop sunaudiodev What's wrong is that the Python 2.6 build script is looking for some antiquated packages that aren't in a current RHEL. Those need to be turned off. They don't need to be turned off. They can either be ignored (because they aren't needed, and did not cause the build to fail), or the development libraries for those pieces can be installed and python recompiled. The rest of the thread has been commenting on the OP's choice of python version and operating system. That's not exactly on topic, but the original question was answered in the very first response. -- Jerry -- http://mail.python.org/mailman/listinfo/python-list
python 6 compilation failure on RHEL
Hi All, We are trying python 2.6 installation on an RHEL PC , whose 'uname -a' is (Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux ) But, python compilation is not successfully done and showing a failure log. Below is the capture of the same. Please see failure log shown in the bottom of this mail. How to solve the failure modules mentioned in the log ( bsddb185, dl , imageop, sunaudiodev ) Please guide me to proceed further. == capture begin = cd Python- 2.6.6 # ./configure checking for --enable-universalsdk... no checking for --with-universal-archs... 32-bit checking MACHDEP... linux2 checking EXTRAPLATDIR... checking machine type as reported by uname -m... x86_64 checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for --with-cxx-main=compiler... no checking for g++... g++ configure: WARNING: By default, distutils will build C++ extension modules with g++. If this is not intended, then set CXX on the configure command line. checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(MAINCC) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for svnversion... found checking for a BSD-compatible install... /usr/bin/install -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether gcc supports ParseTuple __format__... no checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no checking whether gcc accepts -Kthread... no checking whether gcc accepts -pthread... yes checking whether g++ also accepts flags for thread support... yes checking for ANSI C header files... (cached) yes checking asm/types.h usability... yes checking asm/types.h presence... yes checking for asm/types.h... yes checking conio.h usability... no checking conio.h presence... no checking for conio.h... no checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.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 ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking io.h usability... no checking io.h presence... no checking for io.h... no checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking process.h usability... no checking process.h presence... no checking for process.h... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking shadow.h usability... yes checking shadow.h presence... yes checking for shadow.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking for stdint.h... (cached) yes checking stropts.h usability... yes checking stropts.h presence... yes checking for stropts.h... yes checking termios.h usability... yes checking termios.h presence... yes
Re: python 6 compilation failure on RHEL
On 8/20/2012 6:31 AM Ganesh Reddy K said... But, python compilation is not successfully done and showing a failure log. Below is the capture of the same. Please see failure log shown in the bottom of this mail. How to solve the failure modules mentioned in the log ( bsddb185, dl , imageop, sunaudiodev ) Please guide me to proceed further. You're done, unless you specifically need support for any of those specific modules. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On Mon, Aug 20, 2012 at 3:31 PM, Ganesh Reddy K ganeshred...@gmail.com wrote: Hi All, We are trying python 2.6 installation on an RHEL PC , whose 'uname -a' is (Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux ) But, python compilation is not successfully done and showing a failure log. Below is the capture of the same. Please see failure log shown in the bottom of this mail. How to solve the failure modules mentioned in the log ( bsddb185, dl , imageop, sunaudiodev ) Please guide me to proceed further. == capture begin = cd Python- 2.6.6 # ./configure checking for --enable-universalsdk... no checking for --with-universal-archs... 32-bit checking MACHDEP... linux2 checking EXTRAPLATDIR... checking machine type as reported by uname -m... x86_64 checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for --with-cxx-main=compiler... no checking for g++... g++ configure: WARNING: By default, distutils will build C++ extension modules with g++. If this is not intended, then set CXX on the configure command line. checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(MAINCC) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for svnversion... found checking for a BSD-compatible install... /usr/bin/install -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether gcc supports ParseTuple __format__... no checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no checking whether gcc accepts -Kthread... no checking whether gcc accepts -pthread... yes checking whether g++ also accepts flags for thread support... yes checking for ANSI C header files... (cached) yes checking asm/types.h usability... yes checking asm/types.h presence... yes checking for asm/types.h... yes checking conio.h usability... no checking conio.h presence... no checking for conio.h... no checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.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 ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking io.h usability... no checking io.h presence... no checking for io.h... no checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking process.h usability... no checking process.h presence... no checking for process.h... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking shadow.h usability... yes checking shadow.h presence... yes checking for shadow.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking
Re: python 6 compilation failure on RHEL
On Mon, 20 Aug 2012 19:12:05 +0200, Kwpolska wrote: On Mon, Aug 20, 2012 at 3:31 PM, Ganesh Reddy K ganeshred...@gmail.com wrote: Hi All, We are trying python 2.6 installation on an RHEL PC , whose 'uname -a' is (Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux ) But, python compilation is not successfully done and showing a failure log. Below is the capture of the same. Please see failure log shown in the bottom of this mail. How to solve the failure modules mentioned in the log ( bsddb185, dl , imageop, sunaudiodev ) Please guide me to proceed further. == capture begin = cd Python- 2.6.6 # ./configure checking for --enable-universalsdk... no checking for --with-universal-archs... 32-bit checking MACHDEP... linux2 checking EXTRAPLATDIR... checking machine type as reported by uname -m... x86_64 checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for --with-cxx-main=compiler... no checking for g++... g++ configure: WARNING: By default, distutils will build C++ extension modules with g++. If this is not intended, then set CXX on the configure command line. checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(MAINCC) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for svnversion... found checking for a BSD-compatible install... /usr/bin/install -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether gcc supports ParseTuple __format__... no checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no checking whether gcc accepts -Kthread... no checking whether gcc accepts -pthread... yes checking whether g++ also accepts flags for thread support... yes checking for ANSI C header files... (cached) yes checking asm/types.h usability... yes checking asm/types.h presence... yes checking for asm/types.h... yes checking conio.h usability... no checking conio.h presence... no checking for conio.h... no checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.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 ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking io.h usability... no checking io.h presence... no checking for io.h... no checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking process.h usability... no checking process.h presence... no checking for process.h... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking shadow.h usability... yes checking shadow.h presence... yes checking for shadow.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes
Re: python 6 compilation failure on RHEL
On 8/20/2012 10:20 AM Walter Hurry said... On Mon, 20 Aug 2012 19:12:05 +0200, Kwpolska wrote: snip 300+ lines of non-referred to content replicated by you both Do you really need to compile python2.6? RHEL has packages for python, and it's better s/better/sometimes easier to use pre-compiled packages rather than compile them yourself. I concur, but FYI the version of Python with RHEL5 is 2.4. Still, OP should stick with that unless there is a pressing reason. Hence, the 2.6 install. Learn-to-trim-ly y'rs, Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On Mon, 20 Aug 2012 11:02:25 -0700, Emile van Sebille wrote: On 8/20/2012 10:20 AM Walter Hurry said... On Mon, 20 Aug 2012 19:12:05 +0200, Kwpolska wrote: snip 300+ lines of non-referred to content replicated by you both Do you really need to compile python2.6? RHEL has packages for python, and it's better s/better/sometimes easier to use pre-compiled packages rather than compile them yourself. I concur, but FYI the version of Python with RHEL5 is 2.4. Still, OP should stick with that unless there is a pressing reason. Hence, the 2.6 install. First, sorry for my omission to trim. Second, the reason for recommending that OP stick to the Red Hat provided version (unless there is a pressing reason) is the question of the already-paid-for Red Hat support. And for that matter, if OP is forced to a later Python 2 version than 2.4, why not 2.7.3? -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On 8/20/2012 11:37 AM Walter Hurry said... On Mon, 20 Aug 2012 11:02:25 -0700, Emile van Sebille wrote: On 8/20/2012 10:20 AM Walter Hurry said... I concur, but FYI the version of Python with RHEL5 is 2.4. Still, OP should stick with that unless there is a pressing reason. Hence, the 2.6 install. First, sorry for my omission to trim. Second, the reason for recommending that OP stick to the Red Hat provided version (unless there is a pressing reason) is the question of the already-paid-for Red Hat support. Generally, when you compile from source the binaries will install to /usr/local/bin and not be in conflict with RH's install version. And for that matter, if OP is forced to a later Python 2 version than 2.4, why not 2.7.3? Package dependencies. If the OP intends to install a package that doesn't support other than 2.6, you install 2.6. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On Mon, 20 Aug 2012 12:19:23 -0700, Emile van Sebille wrote: Package dependencies. If the OP intends to install a package that doesn't support other than 2.6, you install 2.6. It would be a pretty poor third party package which specified Python 2.6 exactly, rather than (say) Python 2.6 or later, but not Python 3 -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On 8/20/2012 1:55 PM Walter Hurry said... On Mon, 20 Aug 2012 12:19:23 -0700, Emile van Sebille wrote: Package dependencies. If the OP intends to install a package that doesn't support other than 2.6, you install 2.6. It would be a pretty poor third party package which specified Python 2.6 exactly, rather than (say) Python 2.6 or later, but not Python 3 It doesn't need to be a poorly supported third party package to require a non-current version of python -- just something as simple as an up and running application. Suppose you're migrating an application to new hardware. To make it interesting, assume it's a 10 year old zope application. It's likely that to minimize effort you'll gather (assuming you didn't save your sources - you do install from source, right?) and install the versions prescribed. Of course, if you're comfortable upgrading to the latest release then then, by all means, do so. For me, python is used for for dozens of rather significant one-offs that I prefer not to upgrade. Why mess with a working app. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On 20Aug2012 12:19, Emile van Sebille em...@fenx.com wrote: | On 8/20/2012 11:37 AM Walter Hurry said... | On Mon, 20 Aug 2012 11:02:25 -0700, Emile van Sebille wrote: | On 8/20/2012 10:20 AM Walter Hurry said... | I concur, but FYI the version of Python with RHEL5 is 2.4. Still, OP | should stick with that unless there is a pressing reason. | | Hence, the 2.6 install. | | First, sorry for my omission to trim. | | Second, the reason for recommending that OP stick to the Red Hat provided | version (unless there is a pressing reason) is the question of the | already-paid-for Red Hat support. | | Generally, when you compile from source the binaries will install to | /usr/local/bin and not be in conflict with RH's install version. I was going to chime in with this anyway had the thread said nothing; I strongly prefer to specify --prefix explicitly with configure. My personal habit to to build with (adjust to match): --prefix=/usr/local/python-2.6.4 and put some symlinks in /usr/local/bin afterwards (python2.6, etc). That way one doesn't tread on the system Python (after all the OS vendor distro is also a collection of packages with coordinated versions) and one can easily put in another python beside it. | And for that matter, if OP is forced to a later Python 2 version than | 2.4, why not 2.7.3? | | Package dependencies. If the OP intends to install a package that | doesn't support other than 2.6, you install 2.6. Indeed. And this is a strong reason to keep out of the vendor's /usr filesystem space, also. Cheers, -- Cameron Simpson c...@zip.com.au -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On Mon, Aug 20, 2012 at 10:25 PM, Cameron Simpson c...@zip.com.au wrote: I was going to chime in with this anyway had the thread said nothing; I strongly prefer to specify --prefix explicitly with configure. My personal habit to to build with (adjust to match): --prefix=/usr/local/python-2.6.4 and put some symlinks in /usr/local/bin afterwards (python2.6, etc). That way one doesn't tread on the system Python (after all the OS vendor distro is also a collection of packages with coordinated versions) and one can easily put in another python beside it. +1. I like to build a bunch of representative python versions, and test code on some subset of them - often all of them. I usually do 2.5, 2.6, 2.7, 3.0, 3.1, 3.2 and 3.3, but sometimes I get more specific than that. I'll also do a couple of jython's and pypy's normally. It's remarkable how revealing such a simple thing can be for portability. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
On 8/20/2012 2:50 PM, Emile van Sebille wrote: On 8/20/2012 1:55 PM Walter Hurry said... On Mon, 20 Aug 2012 12:19:23 -0700, Emile van Sebille wrote: Package dependencies. If the OP intends to install a package that doesn't support other than 2.6, you install 2.6. It would be a pretty poor third party package which specified Python 2.6 exactly, rather than (say) Python 2.6 or later, but not Python 3 After a thread of clueless replies, it's clear that nobody responding actually read the build log. Here's the problem: Failed to find the necessary bits to build these modules: bsddb185 dl imageop sunaudiodev What's wrong is that the Python 2.6 build script is looking for some antiquated packages that aren't in a current RHEL. Those need to be turned off. This is a known problem (see http://pythonstarter.blogspot.com/2010/08/bsddb185-sunaudiodev-python-26-ubuntu.html) but, unfortunately, the site with the patch for it (http://www.lysium.de/sw/python2.6-disable-old-modules.patch) is no longer in existence. But someone archived it on Google Code, at http://code.google.com/p/google-earth-enterprise-compliance/source/browse/trunk/googleclient/geo/earth_enterprise/src/third_party/python/python2.6-disable-old-modules.patch so if you apply that patch to the setup.py file for Python 2.6, that ought to help. You might be better off building Python 2.7, but you asked about 2.6. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: python 6 compilation failure on RHEL
John Nagle wrote: On 8/20/2012 2:50 PM, Emile van Sebille wrote: On 8/20/2012 1:55 PM Walter Hurry said... On Mon, 20 Aug 2012 12:19:23 -0700, Emile van Sebille wrote: Package dependencies. If the OP intends to install a package that doesn't support other than 2.6, you install 2.6. It would be a pretty poor third party package which specified Python 2.6 exactly, rather than (say) Python 2.6 or later, but not Python 3 After a thread of clueless replies, it's clear that nobody responding actually read the build log. Here's the problem: There are a lot of clueless statements on websites around the world. I'll just quote the one significant comment on the lysium.de page: There's actually no need to apply your patch to setup.py. Python complains about not being able to build those modules, but it will still build and install just fine without them. #6 Alexander Fairley on 2009-01-19 01:43 which is unfortunately burried under an avalanche of satisfied customer replies. Alexander, you're my hero ;) Failed to find the necessary bits to build these modules: bsddb185 dl imageop sunaudiodev What's wrong is that the Python 2.6 build script is looking for some antiquated packages that aren't in a current RHEL. Those need to be turned off. This is a known problem (see http://pythonstarter.blogspot.com/2010/08/bsddb185-sunaudiodev-python-26- ubuntu.html) but, unfortunately, the site with the patch for it (http://www.lysium.de/sw/python2.6-disable-old-modules.patch) is no longer in existence. But someone archived it on Google Code, at http://code.google.com/p/google-earth-enterprise- compliance/source/browse/trunk/googleclient/geo/earth_enterprise/src/third_party/python/python2.6- disable-old-modules.patch so if you apply that patch to the setup.py file for Python 2.6, that ought to help. That patch prevents setup.py from adding a few names of rarely needed/available modules to the list of missing modules. That's snakeoil. OP: You can safely ignore the error message, the patch has no real-world effect. -- http://mail.python.org/mailman/listinfo/python-list
