graphviz build notes

External packages

The full build requires external libraries that you must
obtain elsewhere. Most, if not all of these are optional
and configure will arrange for reduced functionality if
an external library is not found.
Newer versions of these libraries should be fine, if not, please let
us know.

These libraries (either static or dynamic) and their
interface header files must already be on the system.
It's OK if you install your own copies of these packages,
though you may need to tell make or configure where to find them.
Run "configure --help" for details.

On most Linux distributions these packages are already installed
or installable from packages included in the distribution.
You might need to install some -devel packages to get the include
header files.

Abreviated Build Instructions (GNU tools)

If you are using GNU tools, the recommended method for building graphviz
is the usual:

./configure
make
make install

If you are building from CVS sources, then you will need
to have "libtool", "automake", and "autoconf" installed, then build
with:

./autogen.sh
./configure
make
make install

If you are not building with GNU tools, then there are some old-style
Makefiles that can be used instead. Details below.

Detailed Build Instructions

There are a handful of preprocessor defines that control the
image driver configuration. The generic driver is gd
and it can be configured to generate GIF (no compression),
PNG (lossless compression), JPEG (lossy compression),
and Windows BMP files. The compressors all need zlib.
In the current build we have a top-level config.h file that
defines various symbols, such as:

HAVE_JPEG
HAVE_PNG

Build tools for Unix

You have several choices.

1. (Recommended for Linux) Use configure generated by GNU autoconf.
This often works well on a vanilla Linux distribution with
Tcl/Tk, freetype-devel and libjpeg already installed by root
under /usr. Might work OK with Solaris, too.
Otherwise some adjusting of command line arguments
to configure will be needed.
For Linux you can also just pick up the source tarball
or RPMs here.

First, if you are using sources from CVS, run "./autogen.sh"
to generate the "configure" script. If you are using sources
from graphviz-<version>.tar.gz this autogen.sh step should not be
needed.

Obviously you would change the pathnames to reflect your installation.

Note that the directory ${prefix}/include is automatically searched
for headers, and ${prefix}/lib for libraries.

2. (Recommend for other Unix platforms.) As above, you need
the external packages to be installed somewhere.
Then use old make by editing Config.mk for your architecture
and installation directory. Check settings in makearch/$(ARCH).
See below for further notes on individual platforms.

Then edit Makeargs in the top source directory appropriately
and nmake install. Some fiddling with X11 libs is probably
necessary to compile 'lefty'. This usually involes editing
$INSTALLROOT/lib/lib/Xt or X11 (or less portably, edit nmakefile).
You may also need...

export PACKAGE_tcl=/where/tcl/is/installed

When nmake works, it's absolutely great, but it's usually
some work to get the environment right including the
actions of tools like iffe (the AST equivalent
of what GNU configure does). If you're Lefty
or Dave Korn, you already knew that.

Build tools for win32

Currently we build graphviz on Windows using the MS Visual C++ compiler only.
The project and makefiles can be found in both the CVS tree and the source
distribution package in the $ROOT/windows directory. ($ROOT refers
to the directory where the source tree has been installed.)

Follow the step-by-step procedure given below:

Open the WSH script file $ROOT/windows/winmake.wsf using a text editor
and set the "vc" variable to the location of MS VC++ on your machine.

Execute the $ROOT/windows/winmake.wsf file by double-clicking on the
file within Windows Explorer.

If the script throws errors, you'll need to open the graphviz project in
$ROOT/makearch/win32/static/graphviz.dsw using the MS Visual Studio.
Switch to the "File View" within the MS Visual Studio and trigger project
builds individually.

Follow step 4 for building tools in
$ROOT/makearch/win32/static/tools.dsw.

If you're ambitious, we have also used nmake from
AT&T UWIN to build for both the UWIN environment
and the native win32 platform.

export nativepp=-1
nmake CC=ncc MSWIN32==1

(the nativepp thing seems fixed in UWIN 2.25).

Obviously you need to have native versions
of zlib, libpng, jpeg and freetype. (See step 2 above. Or build them
yourself; see notes below.)

If you're running UWIN, of course, you can always just go
with either the old binaries of graphviz for UWIN
(from Dave Korn's UWIN
site ) or build graphviz as a UWIN program using nmake or gmake.

More win32 notes...

Add extra fluff to globals.h to pull in astwin32.h but #undef _UWIN
when compiling with CC=ncc.

MSVC 5.0 C compiler may die when -O is invoked on neato/splines.c;
this required nmakefile CC.NOOPTIMIZE.

Build png by copying scripts/makefile.gcc to makefile and editing slightly
then gmake install

Build jpeg same as zlib: gmake install-lib install-headers

Needed to hand-craft a lib/lib/z to go with our libz.a in order
to not unintentionally pull in /usr/lib/ast.lib (because of mistakenly
binding the lib/lib/z that goes with /usr/lib/z.lib).

We haven't tried to build tcldot or webdot in win32.

Unix platform-specific build notes

SGI

The default Irix libjpeg is obsolescent. We need at least
version 62. It wasn't at all clear to me where to get sources for
this - eventually I found the source for v61 and patches for v62
using a search engine.

We found that on some platforms (Solaris?)
gd/dotneato and freetype MUST be compiled with the
same C compiler (e.g. gcc, or the native cc).
Otherwise there are are weird stack argument errors in
the call to TT_Open_Face. I don't have time to try
to figure out what's wrong.

Solaris

Put /usr/ccs/bin in PATH

HP-UX

The X11 package must include /usr/contrib/X11R6
as well as the base stuff.

Apple Mac OS/X

dot and neato build with old make. (Didn't bother with tcldot.)

There could still be problems with case-sensitive names,
though we believe we've fixed all the ones we know about.

It's weird that Mac OSX declares lrand48() but it's not
defined in any of the standard system library functions.