This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: OS X (Panther) Framework Install causes version mismatch
Type: Stage:
Components: None Versions:
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: bob.ippolito, brett.cannon, daveron, maparent
Priority: normal Keywords:

Created on 2004-11-19 03:38 by daveron, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg23208 - (view) Author: Dusty Harr (daveron) Date: 2004-11-19 03:38
Installed from source python version 2.3.4 (framework install) I 
am running panther (10.3.6)
Following directions in readme

./configure --enable-framework
sudo make frameworkinstall (this last step fails without root privs, 
maybe docs should include the sudo??)

after this python will give the following error:
Interpreter not initialized (version mismatch?)

I tracked this down to python installing into

when the apple-python is installed into

Aparently it was loading the older librarys from the 
/System/Library folder since it comes before the /Library folder in 
the search path.

to the casual observer however everything seams fine and dandy 
at first because the python binaries are put into /usr/local/bin 
which is also later down the search path than the apple supplied 
ones in /usr/bin ! it is not untill you use the new binaries by 
specifying the full path that you find out they don't even work :)

Deleting /System/Library/Frameworks/Python.Framework resolved 
the issue for me. (i deleted the apple supplied binaries from /usr/
bin as well so these files where un-needed)
msg23209 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-11-24 09:05
Logged In: YES 

This is a configuration problem on your computer, not a general problem 
with installing Python 2.3.4 on a Mac OS X 10.3 system.

This error happens primarily if two Python libraries are linked into the 
same executable.  This can happen if you load an extension compiled 
with the system Python from your custom Python or vice versa.  On Mac 
OS X 10.3, this doesn't have to be the case, as there are linker flags that 
can avoid this situation.  Python 2.3.4 uses these linker flags (at least if 
you have the MACOSX_DEPLOYMENT_TARGET environment variable set to 
"10.3" when you configure).  Python 2.3.0, as shipped by Apple in OS X 
10.3, did not use these flags, so it has this problem.  In this situation, 
Python 2.3.0 can use extensions built with Python 2.3.4, but not vice 

By default /usr/local/bin isn't in the search path at all, IIRC.  If you 
wanted your Python to come first in the path, you should've changed 
your PATH, instead of removing essential system files.  Your 
configuration is now even more broken, and several applications will no 
longer work correctly.

Anyway, this is not really a bug (in Python 2.3.4) at all.
msg23210 - (view) Author: Marc-Antoine Parent (maparent) Date: 2004-11-24 20:22
Logged In: YES 

I agree it could be made more explicit, but a good solution is to ensure 
the Python framework install replaces the one in the system, which can 
be obtained with the following configure flag:
msg23211 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-11-25 04:18
Logged In: YES 

OK, I am closing this as invalid.

Dusty, if you would like to have this be more explicit, please feel free to 
submit a patch to change the wording of anything you feel needs to 
change to make this whole situation clear.
Date User Action Args
2022-04-11 14:56:08adminsetgithub: 41193
2004-11-19 03:38:02daveroncreate