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

On Mar 3, 12:25*pm, Uberman <bhoo...@hotmail.com> 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

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

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

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

On Mar 4, 2:29*am, Uberman <bhoo...@hotmail.com> 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

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

On Mar 6, 6:24*am, Uberman <bhoo...@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/wik...lationOnMacOSX

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