backend_macosx framework check fails with 64bit Python

Derek_Homeier · August 10, 2010, 11:41am

Hi again, cc'ing the matplotlib list this time,

for the latter: when building matplotlib against a fink-installed python compiled in 64bit mode
I found the check for a framework-installed Python (rev 8365) fails, and matplotlib fails to load,
because the MacOS module is not available in 64bit. Actually Apple seems to have made it
still available in their system Python, but it's likely to be a general problem on 64bit OS X installations,
and will be for python3 as well.

I believe I have fixed the patch file issue that came from an accidental edit of
the patch file (off by 1 space character). For the issues below, can you give
me some examples that show the behavior that is broken now, but fixed into your
updated patch? I haven't used matplotlib in a long time.

thanks, the fixed patch in unstable compiles and runs now.
Sorry for the late reply; I found that the issue that my extra patch addressed
actually only seems to exist for x86_64 on Snow Leopard.
It is in fact not directly related to python being built as a framework, but the
"import MacOS" used to check for the framework version fails, since the
MacOS module is not available in 64bit. Or so the python docs state, but Apple
seems to have retrofitted it somehow into their system python, so my test for
"import MacOS" worked with /usr/bin/python even on Snow Leopard.

So the test for MacOS.WMAvailable() that my patch removed can obviously stay
there for 32bit installations, and it would probably be better to just catch the
import error on 64bit systems. I'll try to work something out along those lines,
and probably send it upstream to the matplotlib folks as well, since this should
be a general problem on 64bit systems; and also the MacOS module is going
to be removed altogether in python3.x. I'll keep you posted.

I've put the import inside the check now and have it print the warning in both cases
(assuming Python is not a framework installation if it lacks the MacOS module).
I don't know if there might be an alternative way to check for the framework property
for later, and I just picked an error to raise that seemed sensible - feel free to change
that as necessary.

Cheers,
Derek

MacOS-64bit.patch (1.43 KB)

Friedrich_Romstedt · August 10, 2010, 9:26pm

2010/8/10 Derek Homeier <derek@...873...>:

Hi again, cc'ing the matplotlib list this time,

for the latter: when building matplotlib against a fink-installed python
compiled in 64bit mode
I found the check for a framework-installed Python (rev 8365) fails, and
matplotlib fails to load,
because the MacOS module is not available in 64bit.

Hmm, do you claim that MacOS is in general not available in x86_64?
Just my 2 cents:

pb-d-128-141-26-145:~ Friedrich$ python-32
Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MacOS
^D

pb-d-128-141-26-145:~ Friedrich$ python-64
Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MacOS
^D

This is a self-compiled python.org Python 2.6.5 residing in
/Library/Frameworks/Python.framwork:
./configure --enable-framework --with-universal-archs=intel
--enable-universalsdk=/
with
MACOSX_DEPLOYMENT_TARGET=10.4
GCC=gcc-4.2

Please bear with me, but how does framework/not-framework interfere
with the build of the MacOS module?

(assuming Python is not a framework installation if it lacks the MacOS
module).

Are there more implications? I always thought framework build just
means to put it in /Library/Framworks/Python.framework.

Friedrich

Derek_Homeier · August 10, 2010, 11:04pm

Hi Friedrich,

for the latter: when building matplotlib against a fink-installed python
compiled in 64bit mode
I found the check for a framework-installed Python (rev 8365) fails, and
matplotlib fails to load,
because the MacOS module is not available in 64bit.

Hmm, do you claim that MacOS is in general not available in x86_64?

I intended to, since the fink porting description for Python under OS X 10.6 states so,
and I was also mislead by the statement "not available in 64-bit mode" in
3.12.0 Documentation , but the latter, I realised, applied just to
individual functions (in this case, the last one in the list).
You are right, in principle MacOS.WMAvailable() should still be available ( on x86_64.

Just my 2 cents:

pb-d-128-141-26-145:~ Friedrich$ python-32
Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MacOS
^D

pb-d-128-141-26-145:~ Friedrich$ python-64
Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MacOS
^D

This is a self-compiled python.org Python 2.6.5 residing in
/Library/Frameworks/Python.framwork:
./configure --enable-framework --with-universal-archs=intel
--enable-universalsdk=/
with
MACOSX_DEPLOYMENT_TARGET=10.4
GCC=gcc-4.2

Please bear with me, but how does framework/not-framework interfere
with the build of the MacOS module?

(assuming Python is not a framework installation if it lacks the MacOS
module).

Are there more implications? I always thought framework build just
means to put it in /Library/Framworks/Python.framework.

Good question - all I can tell at this point is that in fink, python is not built as a framework,
merely with
./configure --enable-shared
and on Snow Leopard this fails:

miranda:2843> /sw/bin/python2.6
Python 2.6.5 (r265:79063, Jul 19 2010, 02:30:51)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MacOS

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named MacOS

miranda:2844> /usr/bin/python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
File "/Users/derek/.pythonrc", line 22, in <module>
readline.read_history_file(historyPath)
IOError: [Errno 2] No such file or directory

import MacOS
MacOS.WMAvailable()

True

^D

There is no patch that would have explicitly removed the module in the fink install,
so all I can think of is that not enabling framework and/or SDK build is responsible.
I did not find any hint in the Mac build documentation towards this, though.

If this is a fink-related problem only, of course we'd just need to apply the patch I've
created to the fink package. But matplotlib will probably have to deal with it whenever
it is going to be python3-ready.

Cheers,
Derek

···

--
-------------------------------------------------------------------------
Derek Homeier Institut für Astrophysik Göttingen
Georg-August-Universität Phone: +49 551 39-7980
Friedrich-Hund-Platz 1 Fax: +49 551 39-5043
D-37077 Göttingen, Germany Feet: E.04.104
Web: Homepage of Derek Homeier
-------------------------------------------------------------------------

Michiel_de_Hoon · August 12, 2010, 11:32am

To avoid having to import MacOS, I've implemented the MacOS.WMAvailable() function in src/_macosx.m. The updated version of backend_macosx.py doesn't import MacOS; see revision 8625 in trunk.

--Michiel.

···

--- On Tue, 8/10/10, Derek Homeier <derek@...873...> wrote:

From: Derek Homeier <derek@...873...>
Subject: [matplotlib-devel] backend_macosx framework check fails with 64bit Python
To: matplotlib-devel@lists.sourceforge.net
Date: Tuesday, August 10, 2010, 7:41 AM
Hi again, cc'ing the matplotlib list
this time,

for the latter: when building matplotlib against a
fink-installed python compiled in 64bit mode
I found the check for a framework-installed Python (rev
8365) fails, and matplotlib fails to load,
because the MacOS module is not available in 64bit.
Actually Apple seems to have made it
still available in their system Python, but it's likely to
be a general problem on 64bit OS X installations,
and will be for python3 as well.

>>
>> I believe I have fixed the patch file issue that
came from an accidental edit of
>> the patch file (off by 1 space character).
For the issues below, can you give
>> me some examples that show the behavior that is
broken now, but fixed into your
>> updated patch? I haven't used matplotlib in
a long time.
>
>
> thanks, the fixed patch in unstable compiles and runs
now.
> Sorry for the late reply; I found that the issue that
my extra patch addressed
> actually only seems to exist for x86_64 on Snow
Leopard.
> It is in fact not directly related to python being
built as a framework, but the
> "import MacOS" used to check for the framework version
fails, since the
> MacOS module is not available in 64bit. Or so the
python docs state, but Apple
> seems to have retrofitted it somehow into their system
python, so my test for
> "import MacOS" worked with /usr/bin/python even on
Snow Leopard.
>
> So the test for MacOS.WMAvailable() that my patch
removed can obviously stay
> there for 32bit installations, and it would probably
be better to just catch the
> import error on 64bit systems. I'll try to work
something out along those lines,
> and probably send it upstream to the matplotlib folks
as well, since this should
> be a general problem on 64bit systems; and also the
MacOS module is going
> to be removed altogether in python3.x. I'll keep you
posted.
>
I've put the import inside the check now and have it print
the warning in both cases
(assuming Python is not a framework installation if it
lacks the MacOS module).
I don't know if there might be an alternative way to check
for the framework property
for later, and I just picked an error to raise that seemed
sensible - feel free to change
that as necessary.

Cheers,
Derek
-----Inline Attachment Follows-----

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
-----Inline Attachment Follows-----

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options