2011/11/12 Friedrich Romstedt <friedrichromst...@gmail.com>: > 2011/11/12 Friedrich Romstedt <friedrichromst...@gmail.com>: >> A quick googling of "NISC18030.ttf matplotlib" yields this interesting >> result: >> http://groups.google.com/group/sage-devel/browse_thread/thread/2c538915abc99946 > > And this: http://trac.sagemath.org/sage_trac/ticket/7022. Actually I > got the above from that. > > From there (username is "was", probably William Stein): "All it does > is take the plane vanilla matplotlib-0.99.1.spkg spkg and add a little > script that simply rebuilds f2font.so again using *exactly* the same > command lines used by distutils to build that extension. That's it. > For some reason -- probably involving environment variables (?) -- > this fixes the problem. I consider this a temporary 1-sage release > solution until the matplotlib developers (or me) come up with a real > fix." > > I downloaded that script, and reproduced the functionality with my > framework Python 2.6. The resulting ft2font.so differs binarily from > the original ft2font, and ... indeed it runs smoothly with that > ft2font.so. > > What the hell is happening here? Is it really CXX related? What > environmental variables are set by the mighty distutils?
I made up a patched gcc-4.2 bash script that puts the ``env`` output together with the command to run in logfiles based on timecode. The result is that the only differences in environmental variables are: 1) PLAT=macosx-10.5-intel 2) MACOSX_DEPLOYMENT_TARGET=10.5 I don't know anything about (1). (2) was set at compile time and is correct, but I will check if it affects the thing. I will try to reproduce the original ft2font.so generated by distutils by manual commands, to see what ingredience makes it fail in the end. PLAT has apparently no effect on the byte file size at least. MACOSX_DEPLOYMENT_TARGET makes the file size increase to about the size of the original file. The files do not match binary, I guess there's a time stamp somewhere and a compression involved. Even when the file sizes matched by byte, the contents still differ binary. I will focus on whether MACOSX_DEPLOYMENT_TARGET breaks it or not. Unsetting MACOSX_DEPLOYMENT_TARGET and using hence the default ``10.6`` makes it work. Recompiling manually with MACOSX_DEPLOYMENT_TARGET=10.5 and removing the fontcache generated by the last run makes it fail. So to me this looks pretty much like a gcc-4.2 bug. MACOSX_DEPLOYMENT_TARGET has nothing todo with the source code. It *should* just add a legacy layer. What it apparently does is to compile for 10.5 instead, and maybe add a legacy layer for 10.6? Just speculating. So I think we found it, but we cannot solve it apparently. Only thing is to build libraries for 10.6 with the python.org OS X 10.6-only version, so that we can set the deployment target to 10.6 when building the library (matplotlib). I'm cc'ing the sage people manually since I'm not on sage-devel and don't need it at all. William, Ondrej, FYI. So far, Friedrich ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
