Problem pyton PIL

Ryan Schmidt ryandesign at macports.org
Tue Apr 15 22:24:13 PDT 2014


On Apr 15, 2014, at 21:00, Ned Deily wrote:
> On Apr 15, 2014, at 12:36 , Ryan Schmidt wrote:
>> Anything installed in /Library/Frameworks can potentially cause problems for 
>> MacPorts-installed software, as it might inadvertently find dependencies in 
>> /Library/Frameworks instead of the MacPorts-provided version thereof. This is 
>> similar to the /usr/local problem.
> 
> I don't think that is very likely to be a problem with Pythons.  And, if 
> one pops up, it will likely be pointing out a port that is already 
> broken.  Python framework installations are somewhat odd ducks (and were 
> implemented with some unfortunate choices).  One might think that there 
> is a risk that a port trying to link with a Python shared framework 
> library might get the wrong library.  But because there is a 
> /System/Library/Python.framework (Apple-supplied) and the header and the 
> default link search order include both /Library/Frameworks and 
> /System/Library/Frameworks, ports need to be careful to use the MacPorts 
> locations regardless of whether a /Library/Frameworks/Python.framework 
> exists, e.g. otherwise they'll always incorrectly build/link against 
> either the python.org or the Apple-supplied one.  Secondly, using 
> -framework Python as arguments to compile or link is almost always 
> problematic because Python "abuses" the use of framework versions. 
>  Currently, all Python versions (2.x and 3.x) are installed to the same 
> framework which, AFAICT, makes it nearly impossible to use -framework 
> Python if you want to build or link against a specific Python version, 
> which you almost always want to do.  Instead, build scripts need to use 
> pythonx.y-configure commands to find the proper --includes, --libs, etc, 
> which also work in a platform-independent manner.  Upstream packages 
> that don't do so are broken and probably do not link correctly without 
> portfile patching already.

You may be correct about Python.framework specifically; I haven’t looked into it thoroughly. But as a general MacPorts policy, we don’t support users installing software in /usr/local or /Library/Frameworks because of problems we know doing so has caused others.




More information about the macports-users mailing list