problem building on solaris 10

Hi, my name is Erik, and I have a compiling problem. I hope

    > to get it resolved in fewer than 12 steps.

Hi Erik -- if you succeed, then we'll have convincing proof that
compiling mpl on solaris is easier than giving up the sauce.

    > In particular, I'm the Erik Curiel, referred to in this
    > posting from a few months ago by John Hunter, who had (and
    > still has) problems compiling mpb on solaris 10:

    > http://sourceforge.net/mailarchive/message.php?msg_id=12122609

Remind me whether you are using the solaris compiler or gcc. As far
as I know, people have had more luck with gcc so if this is an option
for you, please use it. Skip Montanaro recently got mpl working on
Solaris with a few hacks to the distutils setup, and Nadia has as
well.

Have you googled this error message (I assume you are still getting
this one)?

  "error: `::btowc" has not been declared"

Some posts suggest that it is a bug in the solaris C++ implementation.
Also, did you follow the advice in the paragraphs you linked to,
specifically

   Fourth from the top and was
   http://lists.schmorp.de/pipermail/rxvt-unicode/2005q2/000092.html .
   This thread is not related to matplotlib, and first response there
   isn"t too helpful, but if you follow the rest of the thread you"ll
   get lots of good information. In particular, this response
   (including all the posts in the thread) looks helpful
   http://lists.schmorp.de/pipermail/rxvt-unicode/2005q2/000104.html

If so, do you have anything to report from these attempts?

    > Although I've asked John multiple times to forward me the
    > information from Mike Rightmire and Thomas Wessell, who, it

So many questions, so little time. And a ring to hold to boot.
You'll have to forgive me.

JDH

I finally got the thing to compile. What I had to do was long and
involved. I'll write it up and slap it on the wiki when I am confident I
know what's going on. For the moment, however, even though it compiles, I
still don't think I know what's going on. I get the following messages
and terminating error when I try to import pylab from the python
interpreter. Any suggestions about where to start looking, and what to
look for, to debug this will be greatly appreciated.

Thanks!

E

$ python
Python 2.4.2 (#1, Oct 3 2005, 14:10:19)
[GCC 3.4.4] on sunos5
Type "help", "copyright", "credits" or "license" for more information.

import pylab

LazyValue::init_type
Value::init_type
BinOp::init_type
Point::init_type
Interval::init_type
Bbox::init_type
Func::init_type
FuncXY::init_type
Transformation::init_type
SeparableTransformation::init_type
NonseparableTransformation::init_type
Affine::init_type
init_nc_transforms
Glyph::init_type
FT2Font::init_type
_transforms_module::new_value
_transforms_module::new_value
_transforms_module::new_point
Point::Point
_transforms_module::new_value
_transforms_module::new_value
_transforms_module::new_point
Point::Point
_transforms_module::new_bbox
Bbox::Bbox
_transforms_module::new_value
_transforms_module::new_value
_transforms_module::new_point
Point::Point
_transforms_module::new_value
_transforms_module::new_value
_transforms_module::new_point
Point::Point
_transforms_module::new_bbox
Bbox::Bbox
_transforms_module::new_func
_transforms_module::new_func
_transforms_module::new_separable_transformation
BBoxTransformation::BBoxTransformation
SeparableTransformation::SeparableTransformation
init_nc_image
Image::init_type
_transforms_module::new_value
Value::~Value
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/erik/util/lib/python2.4/site-packages/pylab.py", line 1, in
?
    from matplotlib.pylab import *
  File "/home/erik/util/lib/python2.4/site-packages/matplotlib/pylab.py",
line 217, in ?
    new_figure_manager, draw_if_interactive, show = pylab_setup()
  File
"/home/erik/util/lib/python2.4/site-packages/matplotlib/backends/__init__.py",
line 24, in pylab_setup
    globals(),locals(),[backend_name])
  File
"/home/erik/util/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py",
line 9, in ?
    from backend_agg import FigureCanvasAgg
  File
"/home/erik/util/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py",
line 94, in ?
    from _nc_backend_agg import RendererAgg as _RendererAgg
ImportError: No module named _nc_backend_agg

Hi Erik -- if you succeed, then we'll have convincing proof that
compiling mpl on solaris is easier than giving up the sauce.

Well, it has turned out to be easier than giving up the sauce (at least
for me), but only by a whisker. In the end, the fix is incredibly simple
(if you consider recompiling python and manually adjusting the
auto-produced pyconfig.h incredibly simple, anyway). After two solid days
of commenting this and that out, recompiling everything and its mother 76
different ways from Sunday, poring over a legion of Solaris sys includes,
slaughtering a few spotlessly white lambs and one pure black sheep,
wrapping the bones and tendons and viscera in a double layer of fat and
burning the offering to Delphic Apollo, I found the answer:

1) download Python 2.4.2
2) after extracting it and running ./configure, edit the generated
pyconfig.h as follows:
  i) if _XOPEN_SOURCE is defined to be 600 (i.e., if the line
  "#define _XOPEN_SOURCE 600" appears in the file), redefine it to
  500
  ii) if _XOPEN_SOURCE_EXTENDED is defined at all (i.e. if the line
        "#define _XOPEN_SOURCE_EXTENDED 1" appears in the file),
  comment out its definition
3) make && make install

The problem was with Solaris's support for the X/Open standards. To make
a long story short, you can use Open Group Technical Standard, Issue 6
(XPG6/UNIX 03/SUSv3) (_XOPEN_SOURCE == 600) if and only if you are using
an ISO C99 compiler. If you use X/Open CAE Specification, Issue 5
(XPG5/UNIX 98/SUSv2) (_XOPEN_SOURCE == 500), you don't have to use an ISO
C99 compiler. For full details, see the Solaris header file
/usr/include/sys/feature_tests.h.

This is why muhpubuh (AKA matplotlib---long story) compiles
on Solaris 10 if you have the big bucks and can afford Sun's OpenStudio 10
compiler. gcc does not have full C99 support yet. In particular, its
lack of support for the wide character library makes the build go
bust. (See, e.g., http://gcc.gnu.org/c99status.html.)

There is one remaining item I find extremely puzzling about the whole
affair, though. Since I don't have a recent glib/gtk+ library installed,
and didn't want to make more hoops for myself to jump through, I attempted
to build muhpuhbuh without gtk+ support. Nothing I did would get it to
build without gtk+ support, though. I finally commented out every line in
setup.py and setupext.py that had anything to with gtk+ (the variables
BUILD_GTKAGG, BUILD_GTK, etc., the conditional code-blocks if BUILD_GTK:,
if BUILD_GTKAGG:, etc., the functions build_gdk, build_gtkagg, etc.), but
to no avail. There, in my
local/lib/python2.4/site-packages/matplotlib/backends/, big as life, are
backend_gtk.py, backend_gtkagg.py, etc. When I tried to import pylab from
the command-line interpreter, I naturally got lots of errors from those
spurious backends complaining about not being able to find libgobject.so,
etc. I finally had to manually change the backend parameter in my
.matplotlibrc to TkAgg to get it to work. What's up with that?

E