Re: Shared library Python on Mac OS X 64-bit

Discussion in 'Python' started by Graham Dumpleton, Mar 3, 2009.

  1. On Mar 3, 12:25 pm, Uberman <> wrote:
    > I'm trying to build a 64-bit version of Python 2.5.1 on Mac OS X 10.5.6 64-bit
    > (Intel processor).  The configure line I'm using is:
    >
    > ./configure --enable-shared --disable-framework --disable-toolbox-glue
    > OPT="-fast -arch x86_64 -Wall -Wstrict-prototypes -fno-common -fPIC"
    > LDFLAGS="-arch x86_64"
    >
    > The system builds, but it absolutely refuses to build the shared libraries.  I
    >  keep getting the 'libpython2.5.a' file, and not the needed *.dylib files.
    > Anybody know how to get this thing to produce shared and not static libraries?
    >   A link to examples or documentation that shows the correct configure
    > parameters?  I would have thought "--enable-shared" would do it, but I guess
    > I'm wrong.


    Why don't you want to use MacOS X Framework libraries? It is the
    better installation method.

    Graham
    Graham Dumpleton, Mar 3, 2009
    #1
    1. Advertising

  2. Uberman schrieb:
    > Graham Dumpleton wrote:
    >> Why don't you want to use MacOS X Framework libraries? It is the
    >> better installation method.

    >
    > Because I'm not installing Python, I'm building it. If I were just interested
    > in installing Python, I wouldn't care whether it was static or shared libraries.
    >
    > This is all very specific to my product. We are not just OS X, but Windows
    > and Linux as well. Because of this, we use an SDK/ folder that has all the
    > third-party dependencies contained within it (in a non-platform way).
    > Frameworks are OS X-specific. I build Python within its distribution folder,
    > and then package that same folder up into an archive that gets deposited into
    > the SDK/ folder. The product then builds against that.


    A framework isn't much more than a dynamically shared library. So you
    could use it to link against. For example, one can load it using ctypes
    without a hitch.

    Diez
    Diez B. Roggisch, Mar 3, 2009
    #2
    1. Advertising

  3. On Mar 4, 2:29 am, Uberman <> wrote:
    > Graham Dumpleton wrote:
    > > Why don't you want to use MacOS X Framework libraries? It is the
    > > better installation method.

    >
    > Because I'm not installing Python, I'm building it.  If I were just interested
    > in installing Python, I wouldn't care whether it was static or shared libraries.
    >
    > This is all very specific to my product.  We are not just OS X, but Windows
    > and Linux as well.  Because of this, we use an SDK/ folder that has all the
    > third-party dependencies contained within it (in a non-platform way).
    > Frameworks are OS X-specific.  I build Python within its distribution folder,
    > and then package that same folder up into an archive that gets deposited into
    > the SDK/ folder.  The product then builds against that.


    I don't understand the problem, you can say where it installs the
    framework, it doesn't have to be under /Library, so can be in your
    special SDK folder. For example:

    ../configure --prefix=/usr/local/python-2.5.4 \
    --enable-framework=/usr/local/python-2.5.4/frameworks \
    --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 \
    --with-universal-archs=all

    This would put stuff under /usr/local/python-2.5.4.

    The only thing am not sure about though is what happens to some MacOS
    X .app stuff it tries to install. I vaguely remember it still tried to
    install them elsewhere, so may have to disable them being installed
    somehow.

    Graham
    Graham Dumpleton, Mar 3, 2009
    #3
  4. On Mar 6, 6:24 am, Uberman <> wrote:
    > Graham Dumpleton wrote:
    >
    > > I don't understand the problem, you can say where it installs the
    > > framework, it doesn't have to be under /Library, so can be in your
    > > special SDK folder. For example:

    >
    > > ./configure --prefix=/usr/local/python-2.5.4  \
    > >  --enable-framework=/usr/local/python-2.5.4/frameworks \
    > >  --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 \
    > >  --with-universal-archs=all

    >
    > > This would put stuff under /usr/local/python-2.5.4.

    >
    > While that looked promising, Graham, it didn't actually address my needs.
    > "--with-universal-archs=all" produces binaries for "ppc" and "i386".  I need
    > 64-bit binaries (i.e., "x86_64").


    That configure line should produce 64 bit framework library to link
    against. It will not produce a 64 bit 'python' executable, but you
    will never achieve that at the moment without hacking the Python build
    scripts. This is because the Python build scripts deliberately remove
    64 bit support out of the 'python' executable even though they remain
    in the Python framework library. From memory this is apparently done
    because tcl/tk libraries aren't 64 bit safe. If you look you will find
    some comment about it in the Python build scripts.

    End result is that you end up with a 64 bit framework that can at
    least be quite happily linked into an embedded system compiled as 64
    bit. I know this works as I do it all the time for mod_wsgi and
    mod_python. Something that is required because OS version of Apache on
    MacOS X runs as 64 bit. If you don't trust that I know what I am
    saying, look at:

    http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX

    which is a description of all the stupid things that can happen with
    32/64 bit on MacOS X, so have had a lot to do with this. One of the
    main problems is people using MacPorts versions of stuff, including
    compilers, which do not support generation of 64 bit objects.

    > Also, after building with your settings,
    > there are no shared libraries produced.  All I get is the static-link library,
    > "libpython2.5.a", which is what I'm getting with every other configuration as
    > well.


    A framework library doesn't have a .so or .dylib if that is what you
    are expecting to find. As example, on my PowerPC MacOS X I have:

    /usr/local/python-3.0-trunk/frameworks/Python.framework/Versions/
    Current/Python

    Note, no extension. This is the actual framework library:

    $ file /usr/local/python-2.5.2/frameworks/Python.framework/Versions/
    Current/Python
    /usr/local/python-2.5.2/frameworks/Python.framework/Versions/Current/
    Python: Mach-O dynamically linked shared library ppc

    Because I am on 32 bit PowerPC haven't actually enabled 64 bit
    architectures.

    So, find that file in your framework installation and run 'file' on it
    to see what architectures it really provides. Ignore what 'file' gives
    you for 'python' executable, as as I said before, it has had 64 bit
    architectures stripped out by Python build scripts. Whether that has
    changed for Python 3.0 though I haven't checked.

    > So, indeed, I now know that I needn't place frameworks into default locations,
    > but that doesn't really get me any closer to producing a 64-bit Python shared
    > library.  Thanks for trying, though.


    It can work. So either you are looking for the wrong thing, or there
    is something broken about your environment or which compiler you are
    using.

    Graham
    Graham Dumpleton, Mar 5, 2009
    #4
    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. Replies:
    3
    Views:
    1,700
    Timothy Bendfelt
    Jan 19, 2007
  2. Replies:
    9
    Views:
    914
    Juha Nieminen
    Aug 22, 2007
  3. Replies:
    1
    Views:
    1,246
    santosh
    Jul 15, 2008
  4. Danny Shevitz
    Replies:
    0
    Views:
    240
    Danny Shevitz
    Mar 15, 2011
  5. Jeff.M
    Replies:
    6
    Views:
    155
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page