GLE Build Notes & General Info
Background and Overview
The GLE Tubing and Extrusion Library is a graphics application
programming interface (API). The library consists of a number
of "C" language subroutines for drawing tubing and extrusions.
The library is distributed in source code form, in a package
that includes documentation, a VRML proposal, Makefiles, and
full source code and header files. It uses the OpenGL (TM)
programming API to perform the actual drawing of the tubing and
GLE is known to run on UNIX(r) and UNIX-like operating systems
such as Linux, AIX, IRIX, Ultrix and HPUX with OpenGL or Mesa.
GLE is also known to run on OS/2 Warp.
A spec file is included for automatically building RedHat RPM's.
The GLE build system uses the GNU automake/autoconf tools. These
tools should allow GLE to build cleanly on virtually all computing
To build the library, simply type configure at the command line
to set things up for your CPU & operating system. Then run
make to compile. Finally, cd to the examples
directory, and run the shell script rundemo to launch each
of the demos in order (from most basic, to advanced).
You may find the following configure flags useful:
- If you have a tesselator that is happy with anything,
including degenerate points, collinear segments, etc.
then define this. Otherwise, don't specify this flag.
Setting this flag provides a minor performance improvement.
I believe that the stock SGI tesselator is "lenient",
despite explicit disclaimers in the documentation.
Early versions of the MesaGL tesselator are not at all
forgiving of degenerate points. This resulted in frequent
crashes and/or hangs. (circa 1997-2000). Recent versions
(as of 2001) seem to work fine. If you have an old version
of MesaGL, do not set --enable-lenient-tess
- Disable texture mapping code. Disabling texture
mapping may provide a very minor performance improvement.
- Compile for old IrisGL/GL-3.2 API. This used to work, but
hasn't been tested in a long time.
- Will compile sources so printf routines will be called instead
of OpenGL routines. Warning: this will generate a *lot* of
If you have difficulties... here are some notes:
- IBM AIX, SGI Irix, HP and DEC Systems
- There are no known compile or run time problems. If you have
difficulty making on these systems, make sure that OpenGL and
GLUT are present. (Note: the new automake/autoconf build process
has *not* been tested on these systems.)
- Linux Systems
- Older MesaGL tesselator was prone to hangs and crashes.
Recent (2001) versions seem to do just fine. There are currently
no other known compile or runtime problems.
- Windows NT/2000 and Windows 95/98
- GLE will compile & run on these Microsoft systems under
several different development environments. The subdirectory
ms-visual-c contains project files. The README
contains additional information.
- Macintosh OS version 9
- GLE has been reported to compile & run on this Apple operating
system using the CodeWarrier development environment, once
some 'standard' modifications are made. (??)
- GL and OpenGL Libraries
- The tubing and extrusion library can be compiled for GL 3.2 or for
OpenGL. By default, the Makefile are configured for OpenGL.
(Warning: the library has NOT been run on GL 3.2 in years, and
so might be broken in minor ways. With tweaking, though it should
- Obtaining the GL, OpenGL and GLUT libraries
- OpenGL is available on most UNIX(R) workstations,
as well as OS/2(R) and Windows NT. Contact your
workstation vendor for more information or visit
OpenGL Web Site
SGI's OpenGL site).
GLE also works with Mesa, a public-domain OpenGL-like
API. Mesa can be found at
The demos require that the GLUT windowing and
utility library be installed. GLUT can be obtained
- GLUT Libraries
- The demos require the GLUT library and headers to be installed.
- Compile time warnings
- You may see some compile time warnings. Ignore these. These occur
because not all compilers correctly handle doubly-index subscripts,
and so the code does some funny business to get around this.
To the best of my knowledge, the code still executes correctly
despite these warnings. Note, however, that my efforts to eliminate
these warning may result in code that old compilers will not be able
to compile, or will compile but not execute correctly.
(In my humble opinion, the way in which the C/C++ language handles
doubly, triply, etc. subscripted arrays is fundamentally broken.
The syntax is not self-consistent. Many important constructs are
undefined by ANSI-C (and C++). In the good old days, when most compilers
were broken in this area anyway, you could happily work around this
with single-index arrays and fancy address calculation. Now that
compilers have been fixed, and, thanks to C++, strict-type-checking
is all the rage, the fundamental short-comings of C/C++ in this
area start becoming horribly apparent.
To put it another way, I agonized over how subscripting should be
handled, and what, if any new types needed to be introduced.
Sadly, I was unable to design code that compiled on most compilers,
AND not introduce new types, AND avoid strict-typechecking warning
messages. Sadly, the result is a horrible mess. )
Last updated: Linas Vepstas July 2001