separate shared libraries or different Linux/Unix

Discussion in 'Python' started by stuntgoat, Oct 29, 2008.

  1. stuntgoat

    stuntgoat Guest

    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 )
     
    stuntgoat, Oct 29, 2008
    #1
    1. Advertising

  2. > 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
     
    Martin v. Löwis, Oct 29, 2008
    #2
    1. Advertising

  3. stuntgoat

    Guest

    >
    > 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
     
    , Nov 4, 2008
    #3
  4. In message
    <>,
    wrote:

    > 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. :)
     
    Lawrence D'Oliveiro, Nov 4, 2008
    #4
  5. > 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
     
    Martin v. Löwis, Nov 4, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. EvgueniB
    Replies:
    1
    Views:
    663
    Anthony Borla
    Dec 15, 2003
  2. Frank Fredstone
    Replies:
    1
    Views:
    463
    Jean-Francois Briere
    Jun 27, 2006
  3. Replies:
    1
    Views:
    559
    Robert Gamble
    Sep 4, 2006
  4. Replies:
    0
    Views:
    621
  5. Replies:
    0
    Views:
    776
Loading...

Share This Page