Surfing the Internet you will find many other examples, such as installing Python 2.7.2 for Django, verifying under mod_wsgi that Django is running from Python 2.7.2 absolute path, but then reporting that Python version was 2.4 (e.g., the Python 2.4 shared lib got used!) Deeply disturbing. When using ldconfig your new sqlite3 executable will get old /usr/lib library.
#PYTHON DOWNLOAD MAC RPM INSTALL#
If you install SQLite as detailed below you may use this comparison: I wanted to do this iBoth of the sqlite3 executables look for a shared lib named libsqlite3.so.0.8.6 but the library is different in each release. The problem is that RPATH entries give precidence to /lib and /usr/lib over /usr/local/lib and any other location you might install new shared libraries.Ī good example is upgrading SQLite from version 3.3.6 to 3.7.9. Using ldconfig is not a robust technique. You can view system RPATH with 'sudo ldconfig -p'.
Normally blogs on the Internet suggest using the CentOS RHEL ldconfig application which modifies the system wide CentOS RHEL environment variable RPATH.
#PYTHON DOWNLOAD MAC RPM HOW TO#
The executables (and libraries that need other libraries) need to be told how to find their shared library. Very important technique for memory limited VPS systems, and really any system. Sharing a big chunk of common memory reduces their individual memory footprints. This single library will be used by all the Python interpreters (e.g., python) running in Apache server child processes and all the command-line executeables running at the time. With Python we may use the -enable-shared flag to create a shared library named libpython2.7.so. When installing new applications such as Python 2.7.2 it is always a good idea to enable the use of shared libraries during the compile. You want to do an alternative (alt) install of Python.īelow is my Guide for a 2.7.2 alt install (just replace your 2.6 version number)Ĭompiling CentOS RHEL Packages from Sources You do NOT want to do this on CentOS!!! In fact installing 2.6 via RPM will probably break yum. I am 99% percent sure that installing Python from any sort of RPM is going to overright the existing Python system install.
Yum -disablerepo=rpmforge install python26-develġ95 packages excluded due to repository priority protections Python26-libs i386 2.6.5-6.el5 epel 667 kĭisabling rpmforge makes yum load the (older and much smaller) package from epel: > Package libffi.i386 0:3.0. set to be updated > Processing Dependency: libffi.so.5 for package: python26 > Processing Dependency: /usr/bin/python2.6 for package: python26-devel > Processing Dependency: libpython2.6.so.1.0 for package: python26-devel > Processing Dependency: python26 = 2.6.5-6.el5 for package: python26-devel This could be tricky if rpmforge is also enabled:ġ693 packages excluded due to repository priority protections