[Visualpython-users] Linux and Mac Unix

Recently there has been a flurry of reports of problems trying to compile
Visual and get VPython working on recent versions of Linux, and on the new
X11 environment available on Mac OSX 10.2. I haven't been able to study the
problems myself yet, but I will summarize the reports here. Those users who
have written to me personally but are not subscribed to the VPython user
list may wish to subscribe to participate more fully in whatever mutual aid
there is within the community.

From Kevin Cole came a note that seems to address the issue about
"random_access_iterator":

I had VPython working fine on my 7.2 system, but had a few minor
glitches getting it going on the RH 8.0 Beta after returning from the
Tech Circus last weekend.  In my case, the fixes (after downloading
the latest and greatest from vpython.org) were:

1) Make sure C++ is installed.  (As I recall, in 8.0, the package name
   changes from "gcc-c++" to "gcc-cpp"  but I won't swear to it.  You
   can check w/ the command "rpm -q gcc-cpp" and/or "rpm -q gcc-c++"
   assuming you've installed it using RPM.)
2) Get the Mandrake Numeric RPM.  Pretty current, and it installs no
   fuss, no muss.
3) As the documentation suggests, make sure you know where all your
   python stuff lives.  Red Hat doesn't put any of it in /usr/local.
   So rip "/local" out wherever you see it.  (I can't recall, but
   I think there was somewhere that I had to remove it that wasn't
   mentioned in the documentation.
4) In my case, I had to change cvisual/CXX/CXX_Config.h, as suggested
   by the README.htm in that directory -- though I was a bit surprised,
   considering the date mentioned:

   ================================================================
   Version 3 (June 18, 1999)

   1.  CXX compiles with EGCS snapshot 19990616. EGCS requires a
       standard library class random_access_iterator that is not
       yet available in some other compilers (such as Windows VC6).
       Therefore a new switch:

            STANDARD_LIBRARY_HAS_ITERATOR_TRAITS

       has been added to CXX_Config.h that you may need to toggle
       if you get an error on the two lines that mention
       random_access_iterator. The current definition is correct
       for VC6 and EGCS-19990616.
   ================================================================

Sven Glatthaar reported:

Impressed by the capabilities of vpython I would like to run it using
Redhat 8.0. After fixing the "random_access_iterator"-problem as it is
described in the archive of this mailing list  and running the
install-script successfully another bug occured:
<
Visual-2002-07-22
Traceback (innermost last)
  File "/usr/share/python-visual/Programs/Demos/bounce.py", line 1, in ?
    from visual import *
ImportError: /usr/lib/libgtkgl.so.5: undefined symbol: glXUseXFont

Program disconnected.
 >
As far as I understand libgtkgl.so.5 is part of the
gtkglarea-1.2.2-10.i386.rpm or gtkglarea-1.2.2-10.src.rpm package. Even
an update of this packages to release 13 doesn't help.

Jonathan Brandmeyer offers this perspective on GTK:

For background, GTK2.0 came out in June 2002, and is currently at version
2.2.1.  Gtk1.x is considered obsolete, and the Linux community is migrating
very rapidly to 2.x.

More than one person has contributed the code to make GtkGLArea fully
compliant with GTK2.x.  However, every patch and code contribution to the
tool has died.  The general consensus on the mailing lists is that as of
about September 2002, GtkGLArea is dead.

However, a replacement is available: GtkGLExt.  This library allows you to
make *any* GTK widget capable of displaying OpenGL stuff.  This project is
under active development, is more complete with regard to GL support, has
fewer bugs, and is compatible with Gtk2.x.  The catch is that GtkGLExt is
_not_ compatible with GTK1.2, and probably never will be.  This means that
older distributions will not be able to support the software,  including the
Linux setup that NCSU currently uses.  Every current distribution of Linux
uses GTK2.x today, so this may not be a serious problem for long.

The added bonus is that GtkGLExt has a close cousin: GtkGLExtmm, a C++ class
interface to the GL.  Basically, if you want a window class that shows GL,
you create a class that inherits from Gtk::GL::Widget and Gtk::Window, and
POOF!  You have a window widget that displays OpenGL.

Extra bonus: Gtk and GtkGLExt run on MS Windows, too.

Joe Heafner reported this concerning the Mac:

You may be interested in the thread I started on VPython on 10.2 in the
Mac OS X > Using Technologies > Unix discussion board on Apple's web
site. Someone has tried compiling Visual under 10.2 and has come across
some issues (too complicated for me to try to include here). Note that
he edited the install script to not install numeric and to not create a
.xinitrc file (Apple's X11 doesn't need one unless you use a window
manager other than the default quartz-wm).