Top Up Prev Next Bottom Contents Index Search

A.5 Troubleshooting

This section lists common difficulties encountered when installing and running Ptolemy. This list is, of course, by no means complete. If you do not find your particular problem here, refer to the section
"Additional resources" on page A-40.

The most recent version of this section can be found on the bottom of the Ptolemy home page at The same file should be available via anonymous ftp from as pub/ptolemy/ptolemy0.7/TROUBLE_SHOOTING_0.7.

A.5.1 Problems with tar files

EOF messages while using tar on Suns

There is a bug in the SunOS 4.1.3 version of /bin/tar. Sometimes a command such as:

gzcat pt-0.7.sun4.tar.gz | ( cd ~ptolemy/..; tar xf - )
may produce error message such as:

tar: read error: unexpected EOF
when reading from a pipe if the tar in the command is Sun's /bin/tar. One workaround is to use GNU tar, another is to use gzcat and dd:

gzcat pt-0.7.sun4.tar.gz | dd conv=sync,block |
( cd ~ptolemy/..; tar xf - )

Another workaround is to uncompress the file first, and then run /bin/tar:

gzcat pt-0.7.sun4.tar.gz > pt-0.7.sun4.tar

cat pt-0.7.sun4.tar | (cd ~ptolemy/..; /bin/tar xf -)

A.5.2 Problems starting pigi

pigi: Command not found

Running the pigi command is the most common way of starting up Ptolemy. If you get a message like:

ptolemy@kahn 2% pigi
pigi: Command not found
ptolemy@kahn 3%
then try the following:

set path = ($PTOLEMY/bin $PTOLEMY/bin.$PTARCH $path)

Mr. Ptolemy window does not come up

Ptolemy consists of two processes, vem and pigiRpc, that communicate via Remote Procedure Calls (RPC). Vem is the first process that starts up, and it produces a vem console window in the upper left corner of the screen and a green demo window just below it. When pigiRpc starts up, you should see a window in the middle of your screen that has the Mr. Ptolemy bitmap and a brief description of the binary you are running.

If the pigiRpc process fails to connect to the vem process, you won't see the Mr. Ptolemy bitmap, and the shift-middle-button menus will not be active. This problem seems to be most common on Linux machines, in part because they are often not on a network. If you are running under Linux and your installation is configured to use the network, then you may need to rebuild Ptolemy from source. See "Linux specific bugs" on page A-38 for more information.

If you are running on a machine that is not connected to a network, you will need to provide some network support for pigi to start up. vem and pigiRpc communicate with each other via RPCs, which require some intra-machine network support. One quick test is that you should be able to ping yourself:

/usr/etc/ping `hostname`

There are several workarounds to this. One is to add the name of your host to the loopback line in /etc/hosts (here we add the name myhostname): 		localhost myhostname
Under FreeBSD, you might have to add a fully qualified domain name. If you do not have a fully qualified domain name, sendmail might have problems. An example /etc/hosts entry would be:		localhost myhostname myhostname.mydomain
Another solution is to use route to route packets to your host through the loopback interface. As root, type:

route add `hostname` localhost 0
See the ping, netstat and route commands for more information about networking.

If the Mr. Ptolemy image fails to come up, another thing to check is that Tycho has the proper tclIndex files. If you try to open a facet by typing `F', and you get a message like:

invalid command name "::tycho::Oct::openFacet"
    while executing
then check to see if the TYCHO environment variable is mis-set. You should be able to run Ptolemy with out setting $TYCHO, so if it is set, try unsetenv TYCHO and then restarting. Also, check to see that $PTOLEMY/tycho/typt/kernel/tclIndex exists. This file is used by pigi to find the ::tycho::Oct::openFacet command at runtime. If it does not exist, create it by running make sources in that directory.

pigi fails to start when put in the background

A common problem occurs when pigi is started in the background and the user has the line

stty tostop
in their .login or .cshrc file. This command configures the terminal to halt any process that is running in the background when it tries to write to the terminal. One fix is to run pigi in the foreground. Another fix is to eliminate this command from your login files.

pigi fails to start up, giving shared library messages

On most platforms, Ptolemy is built using shared libraries. In Ptolemy 0.7, the Solaris2.x, HP and possibly Linux platforms use shared libraries, SunOS4.x does not. See the "Shared Library" appendix for more information about shared libraries.

At run time, if shared libraries cannot be found, you may see a message under HPUX-10.x like:

/usr/lib/ Can't find path for shared library:
Under Solaris 2.x, you might see: /users/cxh/pt/bin.sol2/vem: fatal: can't open file: errno=2
The message that you see may vary but the problem is that the binary cannot find the shared libraries to which it was linked. There are a few reasons this could be happening:

setenv SHLIB_PATH {$PTOLEMY}/lib.{$PTARCH}:\ 
For Solaris, you could type the following command (all on one line):


It is best to place these commands in your ~/.cshrc file. It is possible that you might have to add other directories to the shared library path. For example, the Solaris2.x Ptolemy binaries are compiled with /usr/openwin/lib as the location of the X windows libraries. If your X windows libraries are in another directory, then you will need to add that directory to the shared library path. See "Window system problems" on page A-20.

tycho fails to start up, giving TCL_LIBRARY messages

There are several ways to start up tycho, the Ptolemy syntax manager. $PTOLEMY/bin/tycho is a link to a script that processes command line arguments and starts up the appropriate binary. If you type tycho -pigi, tycho starts up with a binary that includes the Ptolemy system. If you type just tycho, then tycho starts up with the generic itkwish binary that is built from the itcl sources, which does not include any of the Ptolemy system.

If your Ptolemy distribution is not at /users/ptolemy, and you are running from prebuilt binaries, then if you run tycho with the prebuilt generic itkwish binary, you may see messages about:

application-specific initialization failed: can't find /users/ptolemy/tcltk/itcl/lib/tcl7.4/init.tcl; perhaps you need to install Tcl or set your TCL_LIBRARY environment variable?
What's happening here is the itkwish binary we ship has the /users/ptolemy path hard-coded into it and the binary is not finding the libraries it needs. The reason this happens is that we want tycho to be able to run outside of Ptolemy on machines that have only generic itkwish installed from the itcl distribution. There are a few workarounds:

exec $PTOLEMY/bin/tycho $*
For further information about troubleshooting Tycho, see the $PTOLEMY/tycho/doc/troubleshooting.html.

A.5.3 Common problems while running pigi

pxgraph fails to come up or displays a blank window

If the pxgraph program is given exceptional numbers, such as the IEEE floating-point Inf, -Inf, or NaN ("not a number"), then it will issue a cryptic error message "problems with input data" and will fail to display a plot. The stars that use pxgraph are supposed to intercept this and pop up an error message in a window. However, as of this writing, this does not work on all platforms. On such platforms, the error message, unfortunately, goes to the standard output, which may be buried several layers deep in your windowing system. It is also possible for the standard output to be lost, so that no error message appears. Thus, if you get such a pxgraph failure, look for instabilities in your Ptolemy schematic that would cause it to produce such exceptional numbers.

Old flowgraphs do not work (facets are inconsistent)

A pigi schematic contains references to icons. These icons are referenced by their location in the file system, typically using either an absolute path, a path relative to user's home directory, or a path relative to the environment variable PTOLEMY. If the master for any of these icons is not in the expected place, vem will issue a warning, telling you the facet is inconsistent, and there will be blank space in place of the icon in the schematic. To find out what icon masters are missing, run the program masters. Instructions for doing this are given in "Copying and moving designs" on page 2-50. Invalid masters will be labeled "INVALID". You must replace the invalid reference with a reference to a valid master. The tcl script $PTOLEMY/bin/ptfixtree can be useful for changing large numbers of facets. $PTOLEMY/bin/ptfixtree.tcl file contains limited instructions on how to use it.

One typical scenario for users upgrading from an earlier version of Ptolemy is that they will have references to ~ptolemy in the directory tree. But the newer version may be installed somewhere else. One solution is to use the masters program to replace references to ~ptolemy with $PTOLEMY.

Ptolemy simulations do not stop

In the SDF domain, it is possible to have multirate systems where a single iteration fires a very large number of stars. This happens when the number of samples produced or consumed by various connected stars in the system are mutually prime, or they have very large least common multiples. If a simulation is taking an unreasonable amount of time, then look for such mutually prime numbers (e.g, rates such as 53:97). Sometimes, in such circumstances, it can take a long time for the simulation to respond to pushing the "stop" button. It should, however, eventually respond.

Multi-porthole galaxies fail

If a galaxy contains a input or output multi-porthole, and the icon of the galaxy is named Foo.input=2, Foo.output=2, etc., the galaxy will fail to compile. This is because Ptolemy behaves as if anything ending in input=X or output=X must be a star. Avoid using names like Foo.input=3 for galaxies.

Star is a compiled-in star and cannot be dynamically loaded

When you create a new universe (schematic), the domain assigned to the universe by default is SDF. If you create stars in the palette that are from another domain and then try to run the universe, you may get the error message

star `Poisson' is a compiled-in star of domain DE. Cannot dynamically load a compiled-in star class.
The solution is to change the domain of the universe by choosing edit-domain from the pigi menu (the keyboard short cut is `d').

A.5.4 Window system problems

Below we discuss various problems we've seen between Ptolemy and the X window system.

Error: not found

You have not installed the shared library needed by Ptolemy when it is used under OpenWindows. See "Special considerations for use under OpenWindows" on page A-7.

pigi fails to start and gives a message about not finding fonts

The default fonts for vem are specified in the file $PTOLEMY/lib/pigiXRes9, and also and pigiXRes9.cp. These files define a set of X window resources. The file is used if pigi is started with the -bw option. The .pigiXRes9.cp file is used in pigi is started with the -cp option. The definitions in these files can be overridden by the user. For example, a user who prefers to use microscopic fonts could set the X resource as follows:

Vem*font:		*-times-medium-r-normal--*-120-*
If, however, the fonts defined in these files on not available on the system, then the Ptolemy installer should change them in the files $PTOLEMY/lib/pigiXRes9*.

The fonts for Tk (and hence, the fonts for most of the dialog boxes) are specified in $PTOLEMY/lib/tcl/ptkOptions.tcl. These may similarly require modifications at some sites. In the worst case, if many standard fonts are not available, it may be necessary to redefine the default fonts built into the Tk source code, and recompile Tk. You may find the X11 program xlsfonts useful.

Ptolemy startup window only has an OK button

If the Ptolemy startup window does not have the Mr. Ptolemy bitmap and the copyright button, but instead the startup window is very small and has only an OK button, then you probably have font problems, see the section above for details about fonts.

Emacs confuses .pl files with Prolog

The .pl extension used to define Ptolemy stars is the same extension used for the Prolog language. Some text editors, such as Emacs, have special modes for editing Prolog files. These modes are inappropriate for editing Ptolemy files. You can add the following line to your .emacs file in your home directory:

(setq auto-mode-alist (cons '("\\.pl$" . c++-mode) auto-mode-alist))

Problems with the colormap

Some applications, for example FrameMaker 5, allocate as many colors as they can from the colormap when they start up. This may force applications that are started later (such as pigi) to have access to a very restricted set of colors. If when you start pigi, the welcome window appears in black and white, then you may have such a situation. If the situation is worse, and there are not enough colors in the colormap for vem to start, then you may not even get this far. One solution is simply to exit the offending application (e.g., FrameMaker or Netscape), and restart pigi. A better solution is to configure the offending application to use fewer slots in the colormap. We have found that for FrameMaker 5, the following X resources (placed in your .Xdefaults file) usually solve the problem:

Maker.targetExactColors: 2
Maker.minimumExactColors: 0
Maker.targetColorCube: 4
Maker.minimumColorCube: 1
This still leaves FrameMaker with a very rich set of colors to use. You may need to replace the 2 or 4 with smaller numbers if you have other color-intensive applications running (such as root window pictures of beaches in Tahiti).

The HP window system, VUE, may not display the correct colors when running Ptolemy. If the Vem window appears with white text on a tan background, or if the Ptolemy run window appears blue instead of tan, then VUE is getting the Ptolemy colors wrong.

The solution here is force VUE to use the regular Ptolemy X resources. Before starting pigi, in an xterm, do the following line:
xrdb -load $PTOLEMY/.Xresources
Then run pigi.

The window manager crashes

The window manager twm sometimes crashes when you are running Ptolemy. We do not know why. It seems to be an interaction with Tk. Our solution is to simply restart it. You may wish to make sure your configuration does not log you out when the window manager exits.

Problems with Sun Sparc5s with 24 bit TCX framebuffers

Some Sun Sparc5 machines have a 24 bit framebuffer called a TCX framebuffer. On these machines, vem will fail to start with a message like:

A Serious X Error has occurred:
BadValue (integer parameter out of range for operation)
Request X_QueryColors (minor code 0)
Type `y' to continue, `n' to exit, `a' to abort:
The problem here is that the root window is a TrueColor window, which causes problems with vem. As a workaround, Arnaud LaPrevote suggests starting OpenWindows with

openwin -server Xsun -dev /dev/fb defclass PseudoColor
It seems you can safely ignore the warning message about specified class or parameter not available that occurs during startup. This bug does not occur on the 24 bit UltraSparc framebuffer, so it seems that the vem bug is only tickled by the tcx frame buffer. For more information, see

Problems with Mac X and Ptolemy

Some people have had difficulties running Ptolemy with Mac X. Tze-Wo Leung of Bell Northern Research suggests the following setup for Mac X when using Ptolemy:

Problems with Exceed and Ptolemy

Under Hummingbird Exceed5.0, you may need to start up another X client before starting pigi. If you get an error message like:

Error: UGetFullTechDir: cannot read .Xdefaults `':
UserMain: OpenPaletteInit() failed
then try starting up another X client such as xclock before starting up pigi.

Problems with XFree86

XFree86 3.1 has problems with the vem Edit-Label widget. If you see messages like

A Fatal Xt Toolkit Error has occurred:
Attempt to unmanage a child when parent is not Composite
Type `y' to continue, `n' to exit, `a' to abort
(continuing may have unpredictable consequences):
then the solution is to upgrade to XFree86 3.2.

A.5.5 Problems with the compiler

The first thing to try is compiling a `hello world' program in C or C++. In C++, you should probably try using the stream functions, below is a sample file:

#include <stream.h>
main() { cout << "Hello, Ptolemy.\n"; }
Try compiling the file with g++ -v and -H flags turned on. -v tells you what steps the compiler is running, -H tells you what include files are being read in.

g++ -v -H

Look at each step of the compilation, and pay particular attention to the assembler and loader steps. You can use the -save-temps gcc option to save any temporary files created in each step. Then, if necessary, you can try running each step by hand.

as vs. gas

gcc can use the native assembler or the GNU assembler. Often the GNU assembler is installed as `as'. Check your path to see which version you are getting. gcc can often be configured at compiler build time to use the native assembler or the GNU assembler (gas), but once the compiler is built, you are stuck with one or the other assemblers. The Ptolemy project makes GNU binaries available. Most of the GNU binaries that we distribute use the native assembler, that is, they don't use gas. However, the hppa GNU gcc-2.7.2 binaries use gas. We distribute a gas binary with the hppa GNU gcc-2.7.2 binaries.


To pick up C++ constructors and destructors, g++ can use the native loader or a program called `collect' (for more information, see Joe Buck's g++ Frequently Asked Questions [FAQ] described below). We usually use collect, because it works with the Pure Inc. tools. The collector is usually located at gcc-lib/$PTARCH/COMPILER_VERSION/ld, e.g. the gcc- sun4 collector might be at $PTOLEMY/gnu/sun4/lib/gcc-lib/sun4/ Note that g++ under Solaris2.x does not use collect.

You can pass the collector arguments so that it will print out more information. Try

g++ -v -Wl,-debug
or, if you are within Ptolemy:

make LINKER="g++ -v -Wl,-debug"
If you pass collect the -debug flag, you will get a lot of output. Part of the output will include what binaries and paths collect is using. Below is part of the output the collect -debug generated by a working installation.

ld_file_name        = /usr/bin/ld
c_file_name         = /users/ptolemy/bin.sun4/gcc
nm_file_name        = /usr/sww/bin/gnm
strip_file_name     = /usr/tools/gnu/bin/gstrip
c_file              = /usr/tmp/cca01064.c
o_file              = /usr/tmp/cca01064.o
COLLECT_NAMES       = /users/ptolemy/gnu/sun4/lib/gcc-lib/sun4/
COLLECT_GCC_OPTIONS = -v -L../../lib.sun4 -static -L../../octtools/lib.sun4 -L../../tcltk/tk.sun4/lib -L../../tcltk/tcl.sun4/lib -L/usr/X11/lib -o pigiRpc
COLLECT_GCC         = gcc
If you need to change the *_file_name values, try modifying your $path so that the new program is in front of the program listed. For instance, if, under csh, one wanted to use
instead of /usr/sww/bin/gnm in nm_file_name above, one would type:

set path=($PTOLEMY/bin.$PTARCH $PTOLEMY/bin /usr/local/bin $path)

The collector will also respond to certain environment variables, see the source in the gnu tar overlay at $PTOLEMY/src/gnu/src/gcc/collect2.c.

The collector creates a temporary file that has the constructors and destructors in it. To get collect to save the temporary file, set the following environment variable:

setenv COLLECT_GCC_OPTIONS -save-temps
If the collector is getting an old version of GNU nm, then you could have problems. Passing the collector the -debug flag might help here.

Error: Linker: no constructors in linked-in code!

If you see the above message while linking a new star, then you might be having nm problems. The above message seems to occur under Linux. Joe Buck says that the thing to do is:

The incremental linker is searching the object file for a global symbol that has the form of a constructor for a static or global object. It then calls that constructor. Ptolemy stars use these constructors to "register" themselves on the list of known stars. You can then create instances of your new star by using its clone() method. If it can't find the symbols, then the new star's code isn't accessible.

The "nm" program is used to find the constructor symbols. Perhaps you have an older version of nm on your system? Find the .o file corresponding to your star and execute

/usr/bin/nm -g --no-cplus mystar.o | grep GLOBAL

Environment variables

Certain environment variables can control where the compiler looks for subprograms and include files. These four variables are usually in the Ptolemy distribution so that users can run the prebuilt compiler, even if the distribution is not at /users/ptolemy.

setenv C_INCLUDE_PATH $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH 
See the gcc info format file for a complete list of environment variables. Note that GCC_EXEC_PREFIX must have a trailing slash, "/". The above variables work for Solaris2.x, if you are running SunOS4.1.3, see "Sun OS4 specific bugs" on page A-39. One symptom of having improperly set environment variables is if you see messages about:

ptolemy/src/kernel/isa.h:44: conflicts with new declaration with C linkage
Another symptom is if you have missing strcmp() symbols at link time.

If, under gcc-, you get warnings about `conflict with built in declaration', and your compiler is not installed where it was built, you may need to create a link in your gcc-lib. We have also seen problems with functions that have variable numbers of arguments. If you compile the file with the -v option, you can see what directories gcc is including. You could try creating a link:

(cd $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH/; \ 
          ln -s .. $PTARCH)

Using trace

The SunOS4.1 trace command can be invaluable in determining what a program is doing at run time. If you compile with gcc -v -save-temps then you can try running trace on the various steps, and see each system call. Unfortunately, the filenames are truncated, but often this is enough to see what is going on. Solaris has a similar truss command.

A.5.6 Problems compiling files

There are several ways to handle problems while compiling files. These problems are often caused by strange interactions between .h files, and they occur while compiling a particular file or a set of files. Note that these problems are different than problems that occur during link time, which we discuss in "Missing symbols while linking pigiRpc" on page A-29.

Using cpp to diagnose .h file problems

If you are having problems with include files, try modifying a hello world program (see above) to include those files. Note that you could be getting unexpected substitutions from the C preprocessor cpp, so looking at the cpp output can be useful in solving compiler installations problems and include file problems

The gcc -E and -P options are very useful in wading through include file problems.
-E stops compilation after the C preprocessor runs, and outputs the resulting file. -P strips off the line numbers from the output.

Try using the -E option, and look at the output file. Sometimes the problem will be obvious. Note that if your compile arguments include -o filename.o, then filename.o will have cpp text output, not the usual object file. Note further that in some compilers, the -c option (create a .o file) will override the -E option. If -c does override -E, you will have to grab the output of the make command and place it in a temporary file, say /tmp/doit, edit
/tmp/doit and remove the -c option and then type sh /tmp/doit. If -c does not override -E, and you are within Ptolemy, you can try using the OPTIMIZER makefile flag to pass arguments to the compile. For instance:

make OPTIMIZER=-E Linker.o > Linker.e 
Another approach is to run cpp and then re-run the compiler on the cpp output. In gcc, the -P option strips out the cpp #line comments. You can use -E -P to generate a new file that has all the cpp substitutions in it, and then try compiling the new file:

make OPTIMIZER="-E -P" Linker.o > 
Edit and remove the first line, which will have the gcc command in it. Make tst.o:

make OPTIMIZER="-v -H" tst.o 
Using the gcc arguments -E -dM will tell you what symbols are defined by cpp at the end of the compile. See the gcc man page or the gcc info format file for more information.

Narrowing the problem down.

If you are having strange problems compiling one file, you might want to try to find the smallest file that causes the problem. This method can take time, but it is sometimes the only way to find a solution. One way is to wrap code in #ifdef NEVER ... #endif and narrow the bug down to one function. Changing the #include declarations at the top, and following the include file change can also help here.

Using c++filt to demangle symbols

When a C++ file is compiled, the symbol names found inside a .o file or a library file have been specially processed by the compiler. This special processing is called mangling. The symbol names may look unusual, for example, makeNew__10KnownBlockPCcT1 is the mangled version of KnownBlock::makeNew(char const *, char const *). You may find it useful to be able to convert the mangled symbol names back to the human readable C++ symbol name. Under gcc-, you can use the c++filt program to do the conversion:

cxh@brahe 9% echo "makeNew__10KnownBlockPCcT1" | c++filt
KnownBlock::makeNew(char const *, char const *)
cxh@brahe 10%
On platforms where we distribute the GNU compiler, c++filt can be found at $PTOLEMY/bin.$PTARCH/c++filt.

Sources of information for compiler problems

$PTOLEMY/gnu/common/man/man1/gcc.1 contains the gcc man page. This file is shipped with the prebuilt GNU binaries. You can try placing $PTOLEMY/gnu/common/man in your MANPATH environment variable:

setenv MANPATH $PTOLEMY/gnu/common/man:$MANPATH

$PTOLEMY/gnu/common/info/gcc* contains the GNU Info format documentation. Use Emacs (M-x info) or a program such as tkinfo to view the info pages (tkinfo is available via anonymous FTP from in pub/misc).

$PTOLEMY/src/gnu/g++FAQ.txt is Joe Buck's g++ Frequently Asked Questions document in text format, (g++FAQ and other FAQs are available via anonymous FTP from in pub/usenet/news.answers).

The following FAQs might also help: c.faq hpux.faq solaris2.faq solaris2_porting.faq sun_sysadmin.faq.

A.5.7 Generated code in CGC fails to compile

The Makefile_C target uses the Ptolemy makefile structure to determine platform dependencies in the C language Code Generation (CGC) domain compile command. If you are having problems with platform dependencies, you may want to use the Makefile_C target. Some demos, such as the CGC commandLine demo use the Default-CGC target. The Default-CGC target has the compiler name set as a target parameter, which is usually either gcc or cc. Unfortunately, not all machines are shipped with a working cc binary and not all machines have gcc, so we cannot choose a default that will work in all circumstances. If you do not have the compiler that is listed in the target parameter, you can do any of the following:

cd $PTOLEMY/bin.$PTARCH; ln -s /usr/ccs/bin/cc gcc

The targets in CGC are configured by default with reasonable guesses about the compile and link options that are required to compile the code. However, the actual options required depend on your system configuration. For instance, your default cc compiler may not have been configured to automatically find the X11 include files. You might, therefore, get an error message the Xlib.h cannot be found. You should find out where on your system Xlib.h is installed, use the `T edit-target' command to add a compile option of the form -Lpath_name where path_name is the full path of the directory containing the file. `T edit-Target' is on the shift-middle-button menu.

Certain compilers will change their behavior depending on the values of certain environment variables:

A.5.8 Ptolemy will not recompile

If Ptolemy fails to recompile, you may be using a substantially different version of the GNU compiler. The system is most likely to build if you use the same tools that we used originally. The GNU tools we used are supplied with the Ptolemy distribution. We discuss common Ptolemy compilation problems below. For further information about recompiling Ptolemy, see "Rebuilding Ptolemy From Source" on page A-10 and see Volume 3 of the Ptolemy Almagest, "The Ptolemy Programmer's Manual".

Messages about "unexpected end of line seen" while running make

If you are running a version of make other than GNU make, you may see messages like:

make: Fatal error in reader: ../../mk/, line 52: Unexpected end of line seen
Ptolemy contains GNU make extensions, you must run GNU make to build Ptolemy, even if you are not using the GNU compiler. GNU make binaries are available via anonymous FTP in The Ptolemy binary tar files for hppa, sol2 and sun4 contain GNU make binaries. You can get just the GNU make binary in pub/gnu/$PTARCH/make.gz, where PTARCH is one of hppa, sol2 or sun4, or you can get the GNU make binary, along with the GNU compiler and other binaries in pub/gnu/ptolemy0.7.

Apparently, older versions of GNU make, such as 3.71, can fail with a message like:

../../mk/ *** commands commence before first target. Stop.
If you get such a message, type make -v to see what version of GNU make you are running.

Can I use my own version of Tcl/Tk?

Ptolemy 0.7 uses itcl2.2, which is an extension to Tcl/Tk. If you have itcl2.2 already installed, you may use your installed version. See "Ptolemy and Tcl/Tk" on page A-13. Tycho will not work with itcl2.1, you must use itcl2.2. Tycho is necessary for viewing the contents of stars and other important features.

Can I use my own version of gcc and libg++?

Ptolemy 0.7 uses gcc- and libg++-2.7.2, see "Dynamic linking fails" on page A-30 for information about Gnu versions and Dynamic linking.

To determine what version of gcc you are running, type gcc -v. To determine what version of libg++ you are running look at the libg++ filename.

cxh@kahn 32% gcc -v
Reading specs from /users/ptolemy/gnu/sol2.5/lib/gcc-lib/sparc-sun-solaris2.5.1/
gcc version
cxh@kahn 33% ls /users/ptolemy/gnu/sol2.5/lib/*

Ptolemy is configured to use shared library versions of libg++ and libstdc++ if they are supported on your platform. To compile Ptolemy from scratch, you should be sure that you have these libraries. Under Solaris, the libraries are named and Under HPUX10.x, these libraries are named and A common problem is that the proper version of gcc is installed, but only the static libraries were built.

Under Solaris, you might see error messages like:
ld: fatal: relocations remain against allocatable but non-writable
The fix is to configure gcc and libg++ with --enable-shared and build the shared libraries or to download the prebuilt Gnu binaries. See for more information.

Can't find genStarList or genStarTable during recompilation

The solution is to include $PTOLEMY/bin in your path. We don't include certain files that are derived from other files. In the star directories, .cc and .h files are derived from .pl files, and the file is generated from $PTOLEMY/bin/genStarTable, .

"CGCMakefileTarget.h: No such file or directory" while linking pigiRpc

If you are in $PTOLEMY/obj.$PTARCH/pigiRpc, and you type make, and $PTOLEMY/obj.$PTARCH/domains/cgc/targets/main/CGCMakefileTarget.o does not exist, then make will try to create it. Unfortunately, make does not have the include files right, so CGCMakefileTarget.h is not found. There is nothing particularly special about CGCMakefileTarget.o. It is just first in the list of files on which pigiRpc depends.

The workaround is to run make from $PTOLEMY, rather than $PTOLEMY/obj.$PTARCH.pigiRpc.

Eventually, we would like to fix this so that it is not necessary to build in other directories before building in $PTOLEMY/obj.$PTARCH/pigiRpc. The solution here would be to move more .o files into lib.$PTARCH.

Missing symbols while linking pigiRpc

On the sun4 with libg++-2.5.2, if you compile pigiRpc with the g++ -O option, then you may have missing symbols while linking pigiRpc. The workaround is to upgrade to a newer version of libg++. If you are using prebuilt GNU binaries, then you may need to set some environment variables (see "Environment variables" on page A-24).

If, at link time, you see messages about undefined symbols, and the undefined symbols begin with _vt, then you probably have compiler version incompatibilities. In earlier releases of libg++, we have seen cases where the symbol vt$7istream$3ios is undefined. This symbol should be present in libg++.a, but it seems that if the compiler is not built with -O2, then this symbol will not be present in libg++.a. The workaround is to rebuild the library by hand, with something like:

cd obj.$PTARCH/gnu

make CC=/users/ptolemy/gnu/sun4/bin/gcc CXX=/users/ptolemy/gnu/sun4/bin/g++ CFLAGS="-g -O2" CXXFLAGS="-g -O2"

Note that you can find out what files have the undefined symbols by using the Unix nm command. For example on Suns, the command nm -o $PTOLEMY/lib.sun4/* | grep MySymbol will find all the files that have symbols that contain the string MySymbol. See "Using c++filt to demangle symbols" on page A-26 for information about how to interpret symbol names in a library.

If, at link time, you see messages about undefined ifstream symbols in libptolemy.a, then the problem could be that you are using gcc-2.7.2, but linking against gcc- libraries. Brian Evans pointed out that fix is to remove the libg++ and libstdc++ libraries in $PTOLEMY/gnu/$PTARCH/lib and create symbolic links to your local Gnu installation.

A.5.9 Dynamic linking fails

Ptolemy has the ability to load stars dynamically during run time. The stars are compiled into .o files and loaded with the Unix loader or with the dlopen() function. Dynamic linking is tricky and dependent on the Unix loader. There are several reasons dynamic linking can fail:

#include <stream.h>
main(){ cout << "Hello, Ptolemy.\n";}

A.5.10 Dynamic linking and makefiles

You may find it easier to use a makefile to build .o files for incremental linking. As part of the incremental linking process, pigi checks for the existence of a Makefile or makefile in the directory where the star resides. If a Makefile or makefile exists, then make XXXStarName.o is run, where XXXStarName.o is the name of the .o file to be incrementally loaded.

Another approach is to create a make.template file in the directory that contains rules to convert the .pl file to a .o file. If the make.template file includes $PTOLEMY/mk/, then most of the configuration is done. For example, to include a star SDFSensorExcitation, with optimization set at -O2, the make.template would contain:
include $(ROOT)/mk/config-$(PTARCH).mk
INCL = -I$(ROOT)/src/domains/sdf/kernel -I$(KERNDIR)
include $(ROOT)/mk/

Then, from a shell, the command to execute would be make -f make.template depend and then, from within pigi, it would be possible to link in the star. See the contents of for complete instructions.

If you have a star that requires multiple .o files, Tom Parks points out that ld -r might help. For example if SDFWirelessChannel.o uses functions from Wireless.o, the following commands might help:

ld -r SDFWirelessChannel.o Wireless.o
mv a.out SDFWirelessChannel.o
To load in multiple stars, you may find the ptcl multilink command useful.

A.5.11 Path and/or environment variables not set in "debug" pigi

When running Ptolemy's interactive graphical interface with the debug option

pigi -debug

the path may not be set correctly, or environment variables are not at their normal values. This is caused by the GNU debugger, gdb, overwriting values set by the pigi start-up script. From the gdb manual:

*Warning:* GDB runs your program using the shell indicated by your \QSHELL' environment variable if it exists (or \Q/bin/sh' if not). If your \QSHELL' variable names a shell that runs an initialization file--such as \Q.cshrc' for C-shell, or \Q.bashrc' for BASH--any variables you set in that file affect your program. You may wish to move setting of environment variables to files that are only run when you sign on, such as \Q.login' or \Q.profile'.
If your .cshrc file specifies a value for a variable, it will override anything in the pigi start-up script. If this is the case, perhaps setting the SHELL environment variable to /bin/sh before firing off the debugger will fix the problem.

1.5.12 DE Performance Issues

DE Performance can be an issue with large, long-running universes. Below we discuss a few potential solutions.

Tom Lane pointed out that the Calendar Queue scheduler can be slower than the old DE scheduler if your time stamps span a wide range. This is because the Calendar Queue Scheduler tries to set up too many bins spanning the range. The old DE scheduler may work faster, as it keeps a queue of current-scheduled events, which is often fairly short.

Tom Lane also pointed out:

If you have both a wide range of timestamps and a lot of future events in the queue at once, you might find it would help to improve the PriorityQueue code to provide a genuine priority queue (i.e., a heap, with O(log N) performance) rather than a simple list like it is now. But you ought to profile first to see if that's really a time sink.
Also, you have to keep in mind that the overhead for selecting a next event and firing a star is not trivial. It helps if your stars do a reasonable amount of useful work per firing. A few other points that may help you:

DE simulation can have certain inherently high cost, so using SDF or DE with SDF functionality inside wormholes can greatly improve performance.

Top Up Prev Next Bottom Contents Index Search

Copyright © 1990-1997, University of California. All rights reserved.