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/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 -- http://mail.python.org/mailman/listinfo/python-list
