separate shared libraries or different Linux/Unix

[stuntgoat]

Hi,

I want to start using Python 2.6 and 3000. I have several questions.

What, in your experiences, is a functionally elegant solution to
installing 2.6 and 3 from source without breaking package dependencies
on your favorite Linux/Unix flavor? Is compiling Python 2.6 and 3.0 on
a *nix development machine and having it work seamlessly as simple as
choosing a particular flavor or are there always going to be package
juggling/mangling/pinning/managing issues affecting the other programs
on the operating system? Is it as simple as choosing a flavor that is
likely to have a Python 3 package available?

Or:

Is there a way to make a copy of shared libraries ( under perhaps /usr/
local/py2.6lib/ and /usr/local/py3lib/ ) so that I can use 2.6 and 3
without causing package problems with other programs within my
operating system? If this seems like a good solution, where can I find
more information about how to implement separate libraries inside the
same OS as appropriate for Python? This might be the better solution
than simply choosing a development flavor of *nix because I am going
to want to install other Python libraries like numpy and matplotlib
from source that might depend on other potentially incompatible shared
libraries than either versions of Python or my Linux/Unix distro ( I
have a feeling I am going to learn how to use ldconfig ).

I have a bit of experience with Debian Etch but I recently garbled my
package management database while compiling the latest version of zlib
for Python 2.6. ( why was I compiling and installing zlib from source?
I was learning another lesson in patience and planning )

 

[Martin v. Löwis]

What, in your experiences, is a functionally elegant solution to

installing 2.6 and 3 from source without breaking package dependencies
on your favorite Linux/Unix flavor? Is compiling Python 2.6 and 3.0 on
a *nix development machine and having it work seamlessly as simple as
choosing a particular flavor or are there always going to be package
juggling/mangling/pinning/managing issues affecting the other programs
on the operating system? Is it as simple as choosing a flavor that is
likely to have a Python 3 package available?

If your distribution provides neither Python 2.6 nor 3.0, then there
shouldn't be any package juggling/mangling/pinning/managing issues
when you build it yourself. Just install it in /usr/local, and be done.

If your distribution does provide those versions, don't build them
yourself at all - just use the distribution ones, and be done.

Is there a way to make a copy of shared libraries ( under perhaps /usr/
local/py2.6lib/ and /usr/local/py3lib/ ) so that I can use 2.6 and 3
without causing package problems with other programs within my
operating system?

You don't need to make copies of shared libraries. Just install
with a prefix of /usr/local, and there won't be any shared library
conflicts. If something invokes the "python" binary without explicit
path, and /usr/local/bin precedes /usr/bin in the path, then it will
pick up your Python interpreter. If you don't want it to, "make
altinstall" instead of "make install" for Python.

If this seems like a good solution, where can I find
more information about how to implement separate libraries inside the
same OS as appropriate for Python?

There is not much information that you need. It Just Works.

This might be the better solution
than simply choosing a development flavor of *nix because I am going
to want to install other Python libraries like numpy and matplotlib
from source that might depend on other potentially incompatible shared
libraries than either versions of Python or my Linux/Unix distro ( I
have a feeling I am going to learn how to use ldconfig ).

Just don't even think of passing --enable-shared to Python's configure,
and it will all work fine, and you won't need to use ldconfig.

I have a bit of experience with Debian Etch but I recently garbled my
package management database while compiling the latest version of zlib
for Python 2.6. ( why was I compiling and installing zlib from source?
I was learning another lesson in patience and planning )

Installing *other* stuff (but Python) from source is something that you
should completely avoid. Instead of installing zlib, you should have
just installed Debian's zlib1g-dev package. Likewise for any other
header files that you will need. The libraries provided by Debian are
sufficient for building Python 2.6 with all extension modules (that
can possibly work on Linux).

Regards,
Martin

 

[chris]

Just don't even think of passing --enable-shared to Python's configure,
and it will all work fine, and you won't need to use ldconfig.

Well I've done --enable-shared so that I can compile mod_python as a
shared object within apache.
Created /etc/ld.so.conf.d/python2.5.conf on a redhat system, and put /
opt/python/lib
and it works no probs.

Installing *other* stuff (but Python) from source is something that you
should completely avoid. Instead of installing zlib, you should have
just installed Debian's zlib1g-dev package. Likewise for any other
header files that you will need. The libraries provided by Debian are
sufficient for building Python 2.6 with all extension modules (that
can possibly work on Linux).

Each to their own. I have a hosted virtual server, and I would like
to get another one for another project.
I want as much built from source as I can manage so that I know what
is and what is not on the system.
zlib is compiled with --enable-shared in /opt/zlib-1.2.3 and I've
ldconfig -n /opt/zlib-1.2.3/lib

I'm compiling python from source, because the server is running redhat
5 which comes with python 2.4
To run trac you need python2.5
I'm running into a problem where zlib is not available even though
there is a copy in /usr/lib/ of the version I compiled.

In /usr/local/src/Python2.5.2 I'm doing:
../configure --enable-shared --prefix=/opt/python --with-zlib=/opt/
zlib-1.2.3
make
make install
When running the setuptools egg, it says zlib unavailable.

Back in the config.log of the Python2.5.2 source directory, it shows
that it's passed in, but in that file there is a --with-system-zlib
How do I get zlib available to python?

Cheers

 

[Lawrence D'Oliveiro]

In message

I want as much built from source as I can manage so that I know what
is and what is not on the system.

Sounds like a job for Gentoo.

 

[Martin v. Löwis]

How do I get zlib available to python?

Edit Modules/Setup, and uncomment the zlib line. At your choice, also
uncomment the *shared* line (otherwise, zlib would become a builtin
module).

When you install shared libraries somewhere that also live in /usr/lib,
do use ldd to verify that it always picks up the libraries you want.

Regards,
Martin