Shared library Python on Mac OS X 64-bit

[Graham Dumpleton]

On Mar 6, 6:24 am, Uberman <bhoo... at hotmail.com> 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