On 09/16/2010 09:27 PM, Jason Grout wrote: > On 9/17/10 1:57 AM, Eric Firing wrote: >> On 09/16/2010 08:21 PM, Christoph Gohlke wrote: >>> >>> >>> On 9/16/2010 8:15 PM, Jason Grout wrote: >>>> On 9/16/10 10:00 PM, Eric Firing wrote: >>>>> On 09/16/2010 04:12 PM, Jason Grout wrote: >>>>>> On 9/16/10 9:03 PM, Jason Grout wrote: >>>>>>> On 9/16/10 8:00 PM, Eric Firing wrote: >>>>>>> >>>>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is >>>>>>>>>> that something is including setjmp.h before libpng.h tries to do so >>>>>>>>>> via >>>>>>>>>> pngconf.h, resulting in an error as the compiler trips over the >>>>>>>>>> following: >>>>>>>>> >>>>>>>> >>>>>>>> Python.h includes pyfpe.h which includes setjmp.h. >>>>>>>> >>>>>>>> Eric >>>>>>>> >>>>>>> >>>>>>> Ah, good catch. So we just need to include Python.h first, and then set >>>>>>> that extra #def so that libpng doesn't try to include it? >>>>>>> >>>>>>> #include "Python.h" >>>>>>> #def PNG_SKIP_SETJMP_CHECK >>>>>>> #include<png.h> >>>>>>> >>>>>> >>>>>> Let me try again: >>>>>> >>>>>> In _backend_agg.cpp and _png.cpp, just add >>>>>> >>>>>> #define PNG_SKIP_SETJMP_CHECK >>>>>> >>>>>> right above >>>>>> >>>>>> #include<png.h> >>>>>> >>>>>> Does that fix it? >>>>> >>>>> Sure does. Your patch with that modification is committed to branch and >>>>> trunk, 8706, 8707. Thank you! >>>>> >>>> >>>> Did someone check on Windows? I was hoping things wouldn't break in >>>> WrapPython.h when I switched the order of includes, but you never know... >>>> >>>> Jason >>> >>> Trunk and 1.0 branch build OK on Windows. >> >> Christoph, >> >> Once again, thanks very much for testing on Windows. >> >> I found a problem on linux (or rather, the buildbot found it because it >> is running an older version) so I have committed one more change to the >> branch. If that survives the buildbot, I will propagate it to the >> trunk, but I don't consider it the last word; I am hoping that someone >> else can do a better job of cleaning this up. >> > > > I see the change that you made (keep the old order for linux, do the new > thing for everything else). This seems like a bad thing to do. Looking > at setjmp.h, it includes features.h. features.h relies on the POSIX and > XOPEN variables that are defined in Python.h to set up the environment, > and the actions from setjmp.h depend on that environment. I think the > warning from the Python docs (if I read correctly) is that the > environment must be set up according to the requirements, and Python.h > sets up those requirements. In other words, by undefining the POSIX and > XOPEN variables, it seems you have a very real likelihood of including a > different setjmp.h in the Python.h compared to the libpng (because the > conditions set up by features.h may be different).
Before making that change, I verified that at least on my linux system, Python.h defines those two variables the same way that features.h does, so the redefinition would be harmless if we did not undefine the variables. I don't think we are any worse off than before with respect to linux, and we should be better off with respect to other platforms--mpl on Solaris now compiles, right?. But I am certainly still not comfortable with the whole setjmp mess. I would love to see someone come up with a clean, clearly understandable solution, and resolve it once and for all. Eric > > Again, I don't see a good way out of the mess. And I guess in this > imperfect world, I can't argue with what appears to work! And as a big > disclaimer; I knew almost nothing about all of this a couple of days ago. > > Thanks, > > Jason > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
