Ports linking against the wrong Python.framework (was: Re: [MacPorts] #19223: subversion 1.6.0 stubbornly linking against python25-apple?)

[Rainer Müller]

Writing to macports-dev to get more public discussion and more people
noticing this problem.

MacPorts wrote:
> #19223: subversion 1.6.0 stubbornly linking against python25-apple?
> ------------------------------------------+---------------------------------
>   Reporter:  macports.org@…               |       Owner:  dluke@…           
>       Type:  defect                       |      Status:  reopened          
>   Priority:  Normal                       |   Milestone:  Port Bugs         
>  Component:  ports                        |     Version:  1.7.1             
> Resolution:                               |    Keywords:                    
>       Port:  subversion-python25bindings  |  
> ------------------------------------------+---------------------------------
> 
> Comment(by dluke@…):
> 
>  So, the libtool link lines in both build logs have:
>  -F/opt/local/Library/Frameworks -framework Python, which should cause the
>  correct Python framework to be chosen, so at this point I'm unsure why
>  it's not working correctly.

And exactly this is wrong. As soon as another framework version (e.g.
2.6 or 3.0) is selected by python_select, it will link against the wrong
python version, but still use the python 2.5 headers. This can lead to
build failures or other problems. After all it is not version which the
maintainer intended, which will result in "Python version mismatch"
later. If none is selected at all, it will even fall back to the system
for linking.

The problem is that frameworks allow to contain multiple versions, but
the compiler does not have any option to choose a specific version. In
my opinion this is a bug. But given this fact, all ports wanting to link
against python need to be patched not to use -framework. This has
already been done for example for mod_wsgi and mod_python25 by
commenting out the framework relevant parts in the configure script.

These multiple versions in one framework cause us more troubles than
benefit. The flags like "-F${prefix}/Library/Frameworks -framework
Python" are generated by build scripts in ports detecting a python
framework. They are not given by the global python configuration, which
only specifies the framework dir and framework name.

We need to get ports not to use these flags. Either we trick ports not
to link using -framework by patching each of them or by modifying the
global python configuration not to report itself as a framework. But
then what would be a reason to keep it as a framework as it causes us so
much troubles?

As far as I know the only advantage of the frameworks is currently to
have working pythonw and IDLE. Is there really no way to get this
without a framework build or did just nobody try yet?

Yes, I know I have been the one who committed the original python
framework transition for python25. :-) It sounded like a good idea back
then and I never thought it would cause such problems for us.

Rainer