Problem pyton PIL

[Ned Deily]

On Apr 15, 2014, at 12:36 , Ryan Schmidt <ryandesign at macports.org> wrote:
> On Apr 15, 2014, at 14:00, Ned Deily wrote: 
> > Ryan Schmidt wrote:
> > > Where did /Library/Frameworks/Python.framework come from? It?s not 
> > > provided 
> > > by Apple, nor any MacPorts port, and will likely interfere with things 
> > > you 
> > > want to install using MacPorts. I recommend you remove it
> > /Library/Frameworks/Python.framework is the installation location for 
> > the Pythons provided by python.org binary installers.  They will happily 
> > co-exist with MacPorts- and Apple-provided Pythons.
> 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.

--
 Ned Deily
 nad at acm.org -- []

-- 
 Ned Deily,
 nad at acm.org