Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
Apologies for the long message---I've really tried to be precise and complete. On 7/7/10 10:23 AM, Jason Grout wrote: > David Kirkby discovered that a recent SVN version of matplotlib did not > compile when he was testing a new matplotlib for inclusion in Sage. A > bug was opened here: > > https://sourceforge.net/tracker/?func=detail&aid=3022815&group_id=80706&atid=560720 > > It appears that a patch has been committed to 1.0.0 which tries to fix > the issue. However, David still reports that matplotlib 1.0.0 still > doesn't compile on Solaris. See: > > http://trac.sagemath.org/sage_trac/ticket/9221?#comment:7 > > I'm not sure what the right procedure for reopening a ticket is. > I've had some time and access to a solaris box today to try to deal with this issue. I think I've solved it, based on a hint from David Kirkby. Again, the issue is that matplotlib 1.0.0 will not compile on the solaris box t2.sagemath.org (and on another Solaris box too). David Kirkby provided the logs and specs for the systems at http://trac.sagemath.org/sage_trac/ticket/9221#comment:7 The error is in compiling CXX: == gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -I/scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/numpy/core/include -I/scratch/grout/sage-4.5.3/local/include -I. -I/scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/numpy/core/include -I/scratch/grout/sage-4.5.3/local/include/freetype2 -I/scratch/grout/sage-4.5.3/local/include -I. -I/scratch/grout/sage-4.5.3/local/include/python2.6 -c src/backend_agg.cpp -o build/temp.solaris-2.10-sun4v-2.6/src/backend_agg.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ In file included from /scratch/grout/sage-4.5.3/local/include/python2.6/Python.h:8, from ./CXX/WrapPython.h:61, from ./CXX/Extensions.hxx:37, from src/ft2font.h:4, from src/backend_agg.cpp:10: /scratch/grout/sage-4.5.3/local/include/python2.6/pyconfig.h:1013:1: warning: "_FILE_OFFSET_BITS" redefined In file included from /usr/include/sys/types.h:18, from /scratch/grout/sage-4.5.3/local/include/zconf.h:364, from /scratch/grout/sage-4.5.3/local/include/zlib.h:34, from /scratch/grout/sage-4.5.3/local/include/png.h:470, from src/backend_agg.cpp:3: /usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed/sys/feature_tests.h:197:1: warning: this is the location of the previous definition In file included from /scratch/grout/sage-4.5.3/local/include/python2.6/Python.h:42, from ./CXX/WrapPython.h:61, from ./CXX/Extensions.hxx:37, from src/ft2font.h:4, from src/backend_agg.cpp:10: /usr/include/stdlib.h:144: error: declaration of C function 'void swab(const char*, char*, ssize_t)' conflicts with /usr/include/unistd.h:496: error: previous declaration 'void swab(const void*, void*, ssize_t)' here error: command 'gcc' failed with exit status 1 == This was reportedly fixed in 1.0.0, but apparently the fix does not work for this Solaris box. Based on a hint from David Kirkby, I changed the CXX/WrapPython.h file to be: == #ifndef __PyCXX_wrap_python_hxx__ #define __PyCXX_wrap_python_hxx__ // On some platforms we have to include time.h to get select defined #if !defined(__WIN32__) && !defined(WIN32) && !defined(_WIN32) && !defined(_WIN64) #include #endif // pull in python definitions #include #endif == (in other words, I just deleted all the defining and undefining of variables). The resulting matplotlib compiled finally, and the result of the testing was: == In [1]: import matplotlib In [2]: matplotlib.__version__ Out[2]: '1.0.0' In [3]: matplotlib.test() /scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/matplotlib/axes.py:2369: UserWarning: Attempting to set identical left==right results in singular transformations; automatically expanding. left=730139.0, right=730139.0 + 'left=%s, right=%s') % (left, right)) -- Ran 138 tests in 755.419s OK (KNOWNFAIL=42) Out[3]: True == so I guess that means everything works. I also compiled it on Ubuntu 10.04 (64-bit) and OSX 10.6.4, and it seemed to compil
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
As a follow-up, I've implemented the patch for CXX and also patches for the other files which do not include Python.h first here: http://github.com/jasongrout/matplotlib/commit/a961c299f5d589dae87e06caf54975eb657ebf3b I've also attached the patch. This patch gets rid of the warnings about redefining things on OSX 10.6.4 (see my last message on this thread). Thanks, Jason diff --git a/CXX/WrapPython.h b/CXX/WrapPython.h index ef97cf1..f62d5b4 100644 --- a/CXX/WrapPython.h +++ b/CXX/WrapPython.h @@ -38,26 +38,12 @@ #ifndef __PyCXX_wrap_python_hxx__ #define __PyCXX_wrap_python_hxx__ +/* Python API mandates Python.h is included *first* */ +#include "Python.h" + // On some platforms we have to include time.h to get select defined #if !defined(__WIN32__) && !defined(WIN32) && !defined(_WIN32) && !defined(_WIN64) #include #endif -// Prevent multiple conflicting definitions of swab from stdlib.h and unistd.h -#if defined(__sun) || defined(sun) -#if defined(_XPG4) -#undef _XPG4 -#endif -#if defined(_XPG3) -#undef _XPG3 -#endif -#endif - -// Python.h will redefine these and generate warning in the process -#undef _XOPEN_SOURCE -#undef _POSIX_C_SOURCE - -// pull in python definitions -#include - #endif diff --git a/src/_backend_agg.cpp b/src/_backend_agg.cpp index 1bf4d97..90f065b 100644 --- a/src/_backend_agg.cpp +++ b/src/_backend_agg.cpp @@ -1,11 +1,9 @@ /* A rewrite of _backend_agg using PyCXX to handle ref counting, etc.. */ -#include -// To remove a gcc warning -#ifdef _POSIX_C_SOURCE -#undef _POSIX_C_SOURCE -#endif +/* Python API mandates Python.h is included *first* */ +#include "Python.h" +#include #include "ft2font.h" #include "_image.h" diff --git a/src/_image.cpp b/src/_image.cpp index b20373f..cd7650a 100644 --- a/src/_image.cpp +++ b/src/_image.cpp @@ -1,8 +1,4 @@ -// To remove a gcc warning -#ifdef _POSIX_C_SOURCE -#undef _POSIX_C_SOURCE -#endif - +/* Python API mandates Python.h is included *first* */ #include "Python.h" #include diff --git a/src/_png.cpp b/src/_png.cpp index 0e71105..57c1862 100644 --- a/src/_png.cpp +++ b/src/_png.cpp @@ -1,9 +1,7 @@ -#include +/* Python API mandates Python.h is included *first* */ +#include "Python.h" -// To remove a gcc warning -#ifdef _POSIX_C_SOURCE -#undef _POSIX_C_SOURCE -#endif +#include // TODO: Un CXX-ify this module #include "CXX/Extensions.hxx" -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Tue, Sep 14, 2010 at 8:21 AM, John Hunter wrote: > > How about this as an alternative: on my box, I can drag the "source > code" link from the browser into my terminal, which by default pastes > the URL of the referenced *.py into the terminal. If "run" supported > a -w (web) option, or automatically detected that the URL starts with > http, it could do a web run of the file. Of course, you may want the > source code pasted in for illustrative purposes... To support this, > you could add a -u (url) option to "paste" which assumes the input is > a url, fetches it, and pastes the contents into ipython. So you could > type "paste -u" and then drag the link into the terminal, and it would > fetch it and paste the code into an input block. Ask and ye shall receive (yes, the url was drag-dropped from the 'source code' link in the mpl page), welcome %loadpy: http://fperez.org/tmp/iqlab_mpl_loadpy.png Full credits go to Brian and Evan! Cheers, f -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Buglets in svg backend?
Howdy, I just wanted to bump this again: given the speed of Michael's recent SVG fixes, maybe fixing these two is also quite easy. They are the only problem coming from matplotlib right now regarding the use of the new qt console for ipython. If not let me know and I'll just file reports on the tracker for long-term storage :) Cheers, f On Tue, Sep 7, 2010 at 3:39 AM, Fernando Perez wrote: > Hi folks, > > I've just implemented support in ipython for simultaneous use of the > interactive mpl gui backends along with inlined figures, as I had > suggested to Eric things could work. > > But I'm seeing two little glitches, illustrated here: > > http://fperez.org/tmp/mpl_svg_bug.png > > The white console on the right is IPython, the mpl window was my only > open figure. > > The code I ran was: > > x=rand(1000) > plot (x) # this pops up the normal gui, I tested Qt4Agg and GTKAgg > > paste() # this pasted the open figure into the IPython console. > > At this point, the plot in the window got that funny size, with the > x-labels double-drawn. It seems as if the figure got re-drawn over > the previous canvas, at a different size. If I resize the window, the > problem goes away, but if I don't resize it, it persists through new > plot/draw operations. > > The second problem... I then zoomed the interactive window and issued > paste again, getting the plot in the bottom right of the figure: > paste() > > And here the bug seems to be related to clipping: while the window > clips OK, the SVG seems not to. > > Is this a fundamental limitation of the SVG backend? > > For IPython we can also switch to pngs if that turns out to work > better, but I figured I'd report these... > > All this was done with current mpl from trunk. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
That's very cool. Unrelated to %loadpy, but is anyone else bothered/confused by the fact that the both the plot in the website and the plot embedded in the app are wrong? There are lines that should be blue (they don't intersect the bbox) in both that are red. I presume this is a bug in either the intersect calculation, or the plot command in the example code. -MinRK On Thu, Sep 16, 2010 at 13:36, Fernando Perez wrote: > On Tue, Sep 14, 2010 at 8:21 AM, John Hunter wrote: > > > > How about this as an alternative: on my box, I can drag the "source > > code" link from the browser into my terminal, which by default pastes > > the URL of the referenced *.py into the terminal. If "run" supported > > a -w (web) option, or automatically detected that the URL starts with > > http, it could do a web run of the file. Of course, you may want the > > source code pasted in for illustrative purposes... To support this, > > you could add a -u (url) option to "paste" which assumes the input is > > a url, fetches it, and pastes the contents into ipython. So you could > > type "paste -u" and then drag the link into the terminal, and it would > > fetch it and paste the code into an input block. > > Ask and ye shall receive (yes, the url was drag-dropped from the > 'source code' link in the mpl page), welcome %loadpy: > > http://fperez.org/tmp/iqlab_mpl_loadpy.png > > Full credits go to Brian and Evan! > > Cheers, > > f > ___ > IPython-dev mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
On 09/16/2010 09:50 AM, Jason Grout wrote: > As a follow-up, I've implemented the patch for CXX and also patches for > the other files which do not include Python.h first here: > > http://github.com/jasongrout/matplotlib/commit/a961c299f5d589dae87e06caf54975eb657ebf3b > > > I've also attached the patch. > > This patch gets rid of the warnings about redefining things on OSX > 10.6.4 (see my last message on this thread). > > Thanks, > > Jason Jason, 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: # ifndef PNG_SKIP_SETJMP_CHECK #ifdef __linux__ # ifdef _BSD_SOURCE #define PNG_SAVE_BSD_SOURCE #undef _BSD_SOURCE # endif # ifdef _SETJMP_H /* If you encounter a compiler error here, see the explanation * near the end of INSTALL. */ __pngconf.h__ in libpng already includes setjmp.h; __dont__ include it again.; # endif #endif /* __linux__ */ # endif /* PNG_SKIP_SETJMP_CHECK */ The relevant part of INSTALL is: If you encounter a compiler error message complaining about the lines __png.h__ already includes setjmp.h; __dont__ include it again.; this means you have compiled another module that includes setjmp.h, which is hazardous because the two modules might not include exactly the same setjmp.h. If you are sure that you know what you are doing and that they are exactly the same, then you can comment out or delete the two lines. Better yet, use the cexcept interface instead, as demonstrated in contrib/visupng of the libpng distribution. For the most part your patch looks like the right thing, but I don't know what to do about this show-stopping glitch. I looked around, but could not figure out what was including setjmp.h after your patch, but not before. Maybe Mike will see it. Eric -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
On 9/16/10 5:24 PM, Eric Firing wrote: > On 09/16/2010 09:50 AM, Jason Grout wrote: >> As a follow-up, I've implemented the patch for CXX and also patches for >> the other files which do not include Python.h first here: >> >> http://github.com/jasongrout/matplotlib/commit/a961c299f5d589dae87e06caf54975eb657ebf3b >> >> >> I've also attached the patch. >> >> This patch gets rid of the warnings about redefining things on OSX >> 10.6.4 (see my last message on this thread). >> >> Thanks, >> >> Jason > > Jason, > > 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: What file caused the error (i.e., what file was compiling?) 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
On 09/16/2010 01:04 PM, Jason Grout wrote: > On 9/16/10 5:24 PM, Eric Firing wrote: >> On 09/16/2010 09:50 AM, Jason Grout wrote: >>> As a follow-up, I've implemented the patch for CXX and also patches for >>> the other files which do not include Python.h first here: >>> >>> http://github.com/jasongrout/matplotlib/commit/a961c299f5d589dae87e06caf54975eb657ebf3b >>> >>> >>> I've also attached the patch. >>> >>> This patch gets rid of the warnings about redefining things on OSX >>> 10.6.4 (see my last message on this thread). >>> >>> Thanks, >>> >>> Jason >> >> Jason, >> >> 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: > > > What file caused the error (i.e., what file was compiling?) Sorry, I wasn't thinking straight, or I would have included that. It was _backend_agg.cpp. However, if I swap the order of inclusion of png.h and Python.h in that file, then redefinition warnings are generated when it compiles, In file included from /usr/include/python2.6/Python.h:8, from src/backend_agg.cpp:6: /usr/include/python2.6/pyconfig.h:1031: warning: "_POSIX_C_SOURCE" redefined //usr/include/features.h:162: note: this is the location of the previous definition /usr/include/python2.6/pyconfig.h:1040: warning: "_XOPEN_SOURCE" redefined //usr/include/features.h:164: note: this is the location of the previous definition ... the compilation proceeds, and then fails with _png.cpp: In file included from /usr/include/libpng12/png.h:518, from src/_png.cpp:4: /usr/include/libpng12/pngconf.h:371: error: expected constructor, destructor, or type conversion before ‘.’ token /usr/include/libpng12/pngconf.h:372: error: ‘__dont__’ does not name a type error: command 'gcc' failed with exit status 1 Eric > > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
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 or something like that? 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
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 > Let me try again: In _backend_agg.cpp and _png.cpp, just add #define PNG_SKIP_SETJMP_CHECK right above #include Does that fix it? 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
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 >> > > Let me try again: > > In _backend_agg.cpp and _png.cpp, just add > > #define PNG_SKIP_SETJMP_CHECK > > right above > > #include > > Does that fix it? Sure does. Your patch with that modification is committed to branch and trunk, 8706, 8707. Thank you! Eric > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
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 >>> >> >> Let me try again: >> >> In _backend_agg.cpp and _png.cpp, just add >> >> #define PNG_SKIP_SETJMP_CHECK >> >> right above >> >> #include >> >> 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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
On 9/16/10 10:15 PM, Jason Grout wrote: >> 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... > Also, since you guys already have a relationship with upstream (CXX), could you report the bug and fix upstream? 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
On 09/16/2010 05: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 >>> >>> Let me try again: >>> >>> In _backend_agg.cpp and _png.cpp, just add >>> >>> #define PNG_SKIP_SETJMP_CHECK >>> >>> right above >>> >>> #include >>> >>> 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, Big trouble, even without Windows. First, after doing more reading, I am far from sure that skipping the check is OK. Second, it doesn't work on earlier Linux versions, for which pngconf.h lacks that SKIP variable entirely. What a pain. I see that Andrew Straw ran into this wall a couple years ago. Time to revert and re-think. It may be that your patch is almost OK, but will need a tweak for Linux. Eric > > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
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 >>> >>> Let me try again: >>> >>> In _backend_agg.cpp and _png.cpp, just add >>> >>> #define PNG_SKIP_SETJMP_CHECK >>> >>> right above >>> >>> #include >>> >>> 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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
On 9/16/10 11:16 PM, Eric Firing wrote: > On 09/16/2010 05: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 > Let me try again: In _backend_agg.cpp and _png.cpp, just add #define PNG_SKIP_SETJMP_CHECK right above #include 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, > > Big trouble, even without Windows. First, after doing more reading, I > am far from sure that skipping the check is OK. Second, it doesn't work > on earlier Linux versions, for which pngconf.h lacks that SKIP variable > entirely. > > What a pain. I see that Andrew Straw ran into this wall a couple years ago. > > Time to revert and re-think. It may be that your patch is almost OK, > but will need a tweak for Linux. An equivalent, but very hackish, fix is to just undef _SETJMP_H. That's almost as bad as the original undef, though. Maybe putting this: #ifdef __linux__ #undef _SETJMP_H #endif #define PNG_SKIP_SETJMP_CHECK right before including png.h would work, at least until distros (eventually) upgrade to a libpng past April 2009 (when the check was added) or until we stop supporting the old distros. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
On 09/16/2010 08:45 PM, Jason Grout wrote: > On 9/16/10 11:16 PM, Eric Firing wrote: >> On 09/16/2010 05: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 >> > > Let me try again: > > In _backend_agg.cpp and _png.cpp, just add > > #define PNG_SKIP_SETJMP_CHECK > > right above > > #include > > 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, >> >> Big trouble, even without Windows. First, after doing more reading, I >> am far from sure that skipping the check is OK. Second, it doesn't work >> on earlier Linux versions, for which pngconf.h lacks that SKIP variable >> entirely. >> >> What a pain. I see that Andrew Straw ran into this wall a couple years ago. >> >> Time to revert and re-think. It may be that your patch is almost OK, >> but will need a tweak for Linux. > > > An equivalent, but very hackish, fix is to just undef _SETJMP_H. That's > almost as bad as the original undef, though. > > Maybe putting this: > > #ifdef __linux__ > #undef _SETJMP_H > #endif > #define PNG_SKIP_SETJMP_CHECK > > right before including png.h would work, at least until distros > (eventually) upgrade to a libpng past April 2009 (when the check was > added) or until we stop supporting the old distros. I don't think that any of these hacks is desirable, so I am trying what I hope is a less-bad hack. Maybe Mike or John will be able to figure out a cleaner solution. I'm still worried about the possibility of a conflict between the versions of setjmp expected by png and by python. I think that if there were such a conflict, it would show up as a crash as part of the error handling in one or the other. Therefore it could lurk undetected for a long time. On the other hand, if there were such a conflict, I don't see how the pre-patched versions would have avoided it any better than the present version. I could not find any evidence that _backend_agg even needs to include png.h, so I deleted that inclusion, leaving only _png.cpp as the trouble spot. Eric > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling on Solaris (and going against the python API)
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 > Let me try again: In _backend_agg.cpp and _png.cpp, just add #define PNG_SKIP_SETJMP_CHECK right above #include 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. Eric > > -- > Christoph -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
