homepage

The libpython3.0.a created for Python 3.0.1 isn't a normal static 
library.
file 
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a: Mach-O universal binary with 3 architectures
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture x86_64):	Mach-O 64-bit 
dynamically linked shared library x86_64
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture i386):	Mach-O dynamically 
linked shared library i386
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture ppc7400):	Mach-O 
dynamically linked shared library ppc
Due to a bug in Darwin's ar, extraction the object files in this 
abnormal static libraries has been possible with 'ar x'. This bug in ar 
will be fixed in the next Xcode and the abnormal static library that 
python creates will no longer be able to serve as a substitute for a 
true static library. The libpython#.#.#.a files in config should be made 
into normal static libraries for all the currently supported versions of 
python when built as frameworks.

Jack: do I understand you correctly when I interpret your message to mean 
that libpython3.0.a inside the Python framework won't be usable as a 
library that's linked using '-lpython3.0' in a future edition of Xcode?
That would be a bummer. The current name was chosen because some 3th party 
code explicitly looks for a '.a' file (IIRC mod_python is one of those).
BTW. libpython3.0 is a symlink to the dylib in the Python.framework, 
specifically to allow applications that try to link to libpython to work.

Jack: could you please explain what the issue is? Unless you do so I 
will close this issue as "won't fix".
In particular: will linking with "-lpython3.0" work with this 
hypothetical future version of Xcode you're talking about? 
As mentioned before "libpythonX.Y.a" is present for compatibility with a 
number of popular 3th-party tools that have manually written makefiles 
that expect this library to be present. Making the file a symlink to the 
actual dylib in the framework seems to work as intented as the moment: 
the executable gets linked to the framework (just as if it was linked 
with "-framework Python")

I'm closing this issue because the user does not respond to my questions 
and because I don't agree there is a problem.