dev-python/matplotlib doesn't compile against Python 2.5 (installed via ~amd64 keyword). This will most likely need to be addressed upstream. (Am I wrong to file it here for completeness?) building 'matplotlib._agg' extension C compiler: x86_64-pc-linux-gnu-gcc -pthread -DNDEBUG -O2 -march=k8 -pipe -fPIC creating build/temp.linux-x86_64-2.5/agg23 creating build/temp.linux-x86_64-2.5/agg23/src compile options: '-Iagg23/include -Isrc -Iswig -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: agg23/src/agg_curves.cpp x86_64-pc-linux-gnu-gcc: agg23/src/agg_trans_affine.cpp x86_64-pc-linux-gnu-gcc: src/agg.cxx src/agg.cxx: In function `int SWIG_Python_ConvertPtr(PyObject*, void**, swig_type_info*, int)': src/agg.cxx:1231: error: invalid conversion from `const char*' to `char*' src/agg.cxx: In function `void SWIG_Python_FixMethods(PyMethodDef*, swig_const_info*, swig_type_info**, swig_type_info**)': src/agg.cxx:27624: error: invalid conversion from `const char*' to `char*' src/agg.cxx: In function `int SWIG_Python_ConvertPtr(PyObject*, void**, swig_type_info*, int)': src/agg.cxx:1231: error: invalid conversion from `const char*' to `char*' src/agg.cxx: In function `void SWIG_Python_FixMethods(PyMethodDef*, swig_const_info*, swig_type_info**, swig_type_info**)': src/agg.cxx:27624: error: invalid conversion from `const char*' to `char*' error: Command "x86_64-pc-linux-gnu-gcc -pthread -DNDEBUG -O2 -march=k8 -pipe -fPIC -Iagg23/include -Isrc -Iswig -I/usr/include/python2.5 -c src/agg.cxx -o build/temp.linux-x86_64-2.5/src/agg.o" failed with exit status 1 !!! ERROR: dev-python/matplotlib-0.87.4 failed.
that's useful. we need people reporting incompat bugs like these.
Created attachment 98696 [details] patches from matplotlib I took patches from http://www.mail-archive.com/matplotlib-devel%40lists.sourceforge.net/msg00293.html and combined in to one file. Compiles well and seems to work...
This is a swig issue, and is similar to bug 148656. It appears that several packages do not rebuild the pre-swigged python elements, even if swig is a dependency. It might be worthwhile creating a swig.eclass that during the unpack phase simply touches *.i in all directories. That ensures that each component takes advantage of the latest swig installed. Is it worth setting up a tracker bug to check the progress of all affected ebuilds? Helmut Jaraush has already created a list of python affected packages, which I've sent to both python@g.o and chriswhite@g.o, since he maintains swig, so it shouldn't be a difficult task...
For reasons that I dont' understand (since I haven't really looked into it), matplotlib-0.87.6 seems to build cleanly even though I had the infamous swig issue w/ 0.87.4. (Note: the fix-bad-win32-detect.patch fails w/ 0.87.6, but after commenting out that line it seems to build just fine.) I just tested it, and it seems to work, too. *Shrug*
I just committed matplotlib 0.87.7 which works with python 2.5 because the bindings were generated with a more recent swig upstream (and are not regenerated during the build process unless explicitly forced). Marking this fixed.
