The users_man/installation chapter has been split into three sections Obtaining Ptolemy Installation Trouble Shooting This text is generated from the users_man/troubleshooting.ps file. This text file contains the latest and greatest version of the installation appendix. The version in the doc.tar.Z file may be out of date with respect to this version. Appendix A Trroubleshooting 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 pageA-39. "Problems with tar files" on pageA-17 "Problems starting pigi" on pageA-18 "Common problems while running pigi" on pageA-20 "Window system problems" on pageA-21 "Problems with the compiler" on pageA-23 "Problems compiling files" on pageA-26 "Generated code in CGC fails to compile" on pageA-27 "Ptolemy will not recompile" on pageA-28 "Dynamic linking fails" on pageA-30 "Dynamic linking and makefiles" on pageA-31 The most recent version of this section can be found on the bottom of the Ptolemy home page at http://ptolemy.eecs.berkeley.edu/. The same file should be available via anonymous ftp from ptolemy.eecs.berkeley.edu as pub/ptolemy/ptolemy0.6/TROUBLE_SHOOTING_0.6. 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.6.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.6.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.6.sun4.tar.gz > pt-0.6.sun4.tar (cd ~ptolemy/..; /bin/tar xf -) A.5.2 Problems starting pigi 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 pageA-37 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 loop back line in /etc/hosts (here we add the name myhostname): 127.0.0.1 localhost myhostname 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. 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 certain platforms, Ptolemy is built using shared libraries. In Ptolemy 0.6, the Solaris, HP and possibly Linux platforms use shared libraries. 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.01 like: /usr/lib/dld.sl: Can't find path for shared library: libuprintf.sl Under Solaris 2.x, you might see: ld.so.1: /users/cxh/pt/bin.sol2/vem: fatal: librpcserver.so: 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: The shared libraries are not where the binary expects them to be. If you are running from prebuilt binaries and your Ptolemy tree is not at /users/ptolemy, then this may be the problem. If you are running from prebuilt binaries and your Ptolemy distribution is not at /users/ptolemy, then you may need to set an environment variable to indicate what path should be searched for shared libraries. Under HPUX, the environment variable is SHLIB_PATH; under Solaris, the environment variable is LD_LIBRARY_PATH. The file $PTOLEMY/.cshrc should contain the proper commands to set the appropriate environment variable, though you may need to uncomment some lines. For HPUX, you could type the following command. (Do not type a space after the \ at the end of the first line, just press Return): setenv SHLIB_PATH {$PTOLEMY}/lib.{$PTARCH}:\ {$PTOLEMY}/octtools/lib.{$PTARCH}:{$PTOLEMY}/gnu/{$PTARCH}/lib For Solaris, you could type the following command (all on one line): setenv LD_LIBRARY_PATH {$PTOLEMY}/lib.{$PTARCH}:\ {$PTOLEMY}/octtools/lib.{$PTARCH}:{$PTOLEMY}/gnu/{$PTARCH}/lib 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 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 pageA-21. You do not have a library with that exact name. You may have an earlier or later version. Recompiling Ptolemy from scratch is one solution. It may also be possible to set up symbolic links to the proper libraries from a directory on the shared library path. 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: Create a link from /users/ptolemy to the Ptolemy distribution. Run tycho -ptiny instead. The tycho script assumes that the Tcl installation is located in $PTOLEMY/tcltk if it is called with the -ptiny, -ptrim or -pigi arguments, so the script will do the right thing. Set environment variables in a script and then call itkwish: #!/bin/sh TCL_LIBRARY=$PTOLEMY/tcltk/itcl/lib/tcl TK_LIBRARY=$PTOLEMY/tcltk/itcl/lib/tk ITCL_LIBRARY=$PTOLEMY/tcltk/itcl/lib/itcl ITK_LIBRARY=$PTOLEMY/tcltk/itcl/lib/itk IWIDGETS_LIBRARY=$PTOLEMY/tcltk/itcl/lib/iwidgets2.0 export TCL_LIBRARY TK_LIBRARY ITCL_LIBRARY export ITK_LIBRARY IWIDGETS_LIBRARY exec $PTOLEMY/bin/tycho $* 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 page2-48. 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: ld.so: libXext.so.4: 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 pageA-8. 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 pigiXRes9.bw and pigiXRes9.cp. These files define a set of X window resources. The pigiXRes9.bw 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. Errors involving xedit The program xedit is a program provided with Ptolemy to display text files on your screen during a Ptolemy run. Over time, we plan on using tycho, the Ptolemy syntax editor, as a replacement for xedit. If there is some problem with xedit that you cannot solve, or you do not like xedit, it is possible to change the display program used by Ptolemy. To do this, you need to set the PT_DISPLAY environment variable before you run pigi. For example, to use PT_DISPLAY to view files in a separate tycho window, do: setenv PT_DISPLAY "tycho %s" To use PT_DISPLAY to view files in a new xterm window with the vi editor, do setenv PT_DISPLAY "xterm -e vi %s" The value of the PT_DISPLAY variable is a printf format string with one %s in it. That %s is replaced with the file to be viewed, for look-inside commands and to view generated code. The default value is "xedit %s". 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 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: My hardware setup is: Mac IIci w/ 20 MBytes DRAM, 210 MB HD and 21" two-page display/21gs Radius B&W monitor. The UNIX server is a HP 715 workstation. The `Display:' option in the `Edit Remote Command' MUST be set to `(2) Color Rootless' mode. Increasing the memory allocation of Mac X to 4 MBytes also helps. The memory size can be increased by first exiting Mac X, then using the `Get Info' option under the File menu to pop-up the file info window where one can change the memory allocation. In the control panel, the characteristics of the monitor are set to `Colors' and `256'. 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 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 hello.cc 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. Collect 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-2.7.2 sun4 collector might be at $PTOLEMY/gnu/sun4/lib/gcc-lib/sun4/2.7.2/ld. 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 hello.cc 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/2.7.2/ld 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 /usr/local/bin/nm 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 (--no-cplus tells nm not to demangle the symbols). You should get some constructor and destructor symbols. 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 GCC_EXEC_PREFIX $PTOLEMY/gnu/$PTARCH/lib/\gcc-lib/$PTARCH/2.7.2/ setenv C_INCLUDE_PATH $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH setenv CPLUS_INCLUDE_PATH $PTOLEMY/gnu/$PTARCH/lib/g++-include:\$PTOLEMY/gnu/$PTARCH/$PTARCH/include setenv LIBRARY_PATH $PTOLEMY/gnu/$PTARCH/lib 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 pageA-38. 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-2.7.2, 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/2.7.2; \ 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 pageA-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 > tst.cc Edit tst.cc 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-2.7.2, 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 ptolemy.eecs.berkeley.edu 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 rtfm.mit.edu 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 In Ptolemy0.6, we've added the Makefile_C target that 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 anyone of the following: Type a `T' while in the facet to bring up the Target Parameters window and change the value of compilerCommand to a compiler that you have. Create a link in $PTOLEMY/bin.$PTARCH for the compiler you don't have. For example, if you don't have gcc, and your cc is at /usr/ccs/bin/cc, you could do cd $PTOLEMY/bin.$PTARCH; ln -s /usr/ccs/bin/cc gcc Use the Makefile_C target instead of the Default-CGC target. (Some demos still use the Default-CGC target so that we can continue to test that target). 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: The hppa cc compiler will use the CCOPTS environment variable. If your X11 libraries were at /usr/sww/X11R5/lib, then one could exit pigi, set the variable setenv CCOPTS -L/usr/sww/X11R5/lib and restart pigi. Then when you compile CGC demos with hppa cc, you should be able to find the proper libraries. See the hppa cc man page for more information. Note that under HPUX10.01, the bundled C compiler is not ANSI compliant so it may fail to compile some CGC Universes. GNU gcc will also use certain environment variables. The LIBRARY_PATH variable may help: setenv LIBRARY_PATH /usr/sww/X11R5/lib See the gcc documentation for more information. 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 pageA-12 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/stars.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 ptolemy.eecs.berkeley.edu. 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.6. Can I use my own version of Tcl/Tk? Ptolemy 0.6 uses itcl2.0, which is an extension to Tcl/Tk. If you have itcl2.0 already installed, you may use your installed version. See "Ptolemy and Tcl/Tk" on pageA-14. 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 domainnamestars.cc 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 work around 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 pageA-25. 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 pageA-27 for information about how to interpret symbol names in a library. 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: If you are upgrading from an earlier release be sure to remove all the .o files in the directory where the source files for you star is located. If you are using prebuilt Ptolemy binaries, be sure that you are using the prebuilt GNU compiler that is also available with the Ptolemy binaries (Ptolemy0.6 was built with gcc-2.7.2/libg++-2.7.1) The alternative is to rebuild Ptolemy with your local GNU compiler, but be aware that versions earlier than gcc-2.5.6 and libg++-2.5.3 have bugs. gcc-2.4.x and libg++-2.4.x and earlier are know to have serious bugs, so you may want to upgrade. For more information, see "Gnu Installation" on pageA-9. If you are using prebuilt Ptolemy binaries and have the prebuilt GNU compiler, be sure that either the Ptolemy distribution is available as /users/ptolemy, or you are setting the GNU environment variables in $PTOLEMY/bin/g++-setup. Again, see the GNU Installation section. If, at link time, you see messages about undefined symbols, then see the section above, "Missing symbols while linking pigiRpc". Dynamic linking may not work on machines using a different release of the operating system than that used to build the Ptolemy binaries. The solution is to rebuild Ptolemy from source. If you are having problems compiling the star from Ptolemy, try running the compile by hand from the shell. Unfortunately, part of the compile command is not always visible in the vem window. To see the all of the compile command, try running a few vem commands, such as `i' (look-inside) to flush the vem buffer. Once you have produced a .o file, you can load the .o file into Ptolemy with the load-star command. If you cannot compile your star from the shell, try compiling a simple c++ program to verify that the compiler is working. Place the code below in a file called hello.cc and if you are using the GNU compiler, try compiling it with g++ -v. The -v option will show the compiler steps. #include main(){ cout << "Hello, Ptolemy.\n";} If you are having problems with undefined symbols at load time, try compiling your star with the same level of optimization as the binary was built with. We ship pigiRpc and ptcl binaries that have been compiled with -O2, so you may want to compile your star with -O2. If you are running under HPUX9.x, and you see messages like: collect2: ld returned 1 exit status /bin/ld: Invalid loader fixup needed then you probably need to create a make.template file to load your stars. The problem here is that Ptolemy attempts to compile your star with default arguments, however, since HPUX9.x uses shl_load() style linking, you need special compiler arguments, so you need a makefile See $PTOLEMY/mk/userstars.mk for more information. You may also need to upgrade your version of the GNU assembler named gas. Version 2.5.2 has been reported to have the problem, while version 2.6 seems to work fine. Note that gas is often named as. If you compiler your star with the g++ -v option, then you will see which assembler the compiler is using. You can then call the assembler with the --version flag to see what version the assembler is. 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/userstars.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: ROOT = $(PTOLEMY) VPATH = . OPTIMIZATION=-O2 include $(ROOT)/mk/config-$(PTARCH).mk INCL = -I$(ROOT)/src/domains/sdf/kernel -I$(KERNDIR) PL_SRCS = SDFSensorExcitation.pl DOMAIN = SDF include $(ROOT)/mk/userstars.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 userstars.mk 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 `SHELL' environment variable if it exists (or `/bin/sh' if not). If your `SHELL' variable names a shell that runs an initialization file--such as `.cshrc' for C-shell, or `.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 `.login' or `.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. If you are running a long simulation, you should be sure that your machine is not paging or worse yet swapping, you should have plenty of memory. Usually 64Mb is enough, though 128Mb can help. Depending on what platform you are on, you may be able to use the program top (ftp://eecs.nwu.edu/pub/top). You might also find it useful to use iostat to see if you are paging or swapping. One way to gain a slight amount of speed is to avoid the GUI interface entirely by using ptcl, which does not have Tk or Higher Order Function (HOF) stars. See "Some hints on advanced uses of ptcl with pigi" on page3-18 for details. A.6 Known bugs There are a number of known bugs that we have not had a chance to fix. You may find useful information about architecture dependencies in $PTOLEMY/mk/config-$PTARCH.mk for the particular architecture you are running under. A.6.1 Bugs in vem When graphical animation is turned on and a simulation is running, if you execute the "look-inside" command, vem terminates the pigiRpc application. Deleting wires that are too long (i.e., end of wire is past the terminal, but near it) can result in vem dumping core. Labels that end with a carriage return are neither displayed nor printed correctly. Editing icons stimulates a memory leak in vem that can make the process grow quite big. After editing a few dozen icons, you may wish to exit vem and restart. The "layer" command only works when editing icons, not when editing schematics. The "copy-objects" command will copy from one window to another only when editing icons, not when editing schematics. vem or pigiRpc may fail to start up on 4 bit (16 color) screens. At UC Berkeley, we use 8 bit and 24 bit screens. Black and white (1 bit) support in vem is a little weak. If you are on a black and white screen, you may need to modify $PTOLEMY/lib/pigiXRes9. (Note that $PTOLEMY/lib/pigiXRes9.bw is read when the -bw pigi options is used to create black and white screen dumps from a color monitor. pigiXRes9.bw has very little to do with running on a black and white screen). If the VEMBINARY environment variable is set, then bin/pigiEnv.csh will use the contents of that variable as the vem binary. However, the binary must be named vem, or there will be minor problems with X resources, such is small fonts and incorrect snap. Most users will never use the VEMBINARY environment variable, it is primarily used to debug vem. If your X server runs out of colors, vem may crash. One workaround is to not run color hogs like netscape, or to limit the number of colors netscape can use. Bug fixes to vem now mean that vem is more picky about text label heights. Currently, the range for text label heights is 0 to 80. If you select text and then use E, to edit the label, you may see an error if your text height is greater than 80. One workaround is to delete the text and reenter it with a height that is within the proper range. Another workaround is to use an old vem binary to edit the height and set it to within the range. If you re-read a facet that has an open run window, you won't be able to dismiss the run window. The workaround is to open a new run window. A.6.2 Bugs in pigi It is possible to make more than one icon to represent a given star. For instance, the icon And and And.input=2 refer to the same star, but the former can have any number of inputs, while the latter has exactly two inputs. As of this writing, this facility does not work for galaxies. You should create only one icon for each galaxy. $PTOLEMY/bin/pigi is a link to $PTOLEMY/bin/pigiEnv.csh which may add to your path. Under certain circumstances, you may get the message `Warning: ridiculously long PATH truncated'. To work around this problem, try shortening your path. One trick is to use shorter pathnames in your path, perhaps using symbolic links. If your X server runs out of colors, pigi may crash. One workaround is to not run color hogs like netscape, or to limit the number of colors netscape can use. The compile-SDF target fails if a galaxy has incrementally linked in stars. The problem is that the .h file for the incrementally linked in star cannot be found by compile-SDF. As a workaround try editing the makefile in ~/PTOLEMY_SYSTEMS and adding the directory where the incrementally linked stars is. Then build the binary by hand. Ptolemy 0.6 contains two new data types in the kernel: String and File. These two new data types should be useful in creating Design Flow Management (DFM) universes. However, there are only a few DFM demos. The Networks Of Workstations active messages (NOWam) CGC target is slow, but it does run under Solaris. To use the Dynamic Dataflow Code Generation (cgddf) CGC target, two files must be recompiled. The cgddf changes in PortHole.cc and Higher Order Functions (HOF) are incompatible, the HOFMapGr star breaks. The changes to parScheduler.cc are a fairly radical shift in how Ptolemy handles disconnected graphs. These changes could break other parallel schedulers. The script $PTOLEMY/bin/mkcgddf will build a pigiRpc.ptrim.debug binary that contains the cgddf target. This script is basically untested, but should work. A.6.3 Bugs in tycho Ptolemy 0.6 contains the first release of tycho, the Ptolemy syntax manager. Development of tycho is ongoing, so the version included in Ptolemy 0.6 is by no means the final version. In particular, there are many more features to be implemented. If you start up tycho with Ptolemy in the background (i.e, tycho -ptrim &), then exiting from the MATLAB console may hang. The workaround is to place your tycho process into the foreground. This is a known bug with MATLAB. A.6.4 Code generation bugs The CGC multirate filterbank and CGC chaoticBits demos bring up messages about initializable delays. If you try to run the CGC demos that generate sound, and you do not have a properly configured audio device, or you do not have write permission to /dev/audio, then you get a cryptic and uninformative error message, rather than something useful. The CGC tremolo demo will probably only work on a Sun SPARCstation running SunOS4.1.3 or Solaris2.x. The CGC alive demo will only work on an SGI. The use of initializable delays and variable delays in the code generation domains may result in incorrect code being generated. Variable delays are delays which depend upon the value of a galaxy or universe parameter. The work around is to use regular delays of a constant value (i.e. "4") in the code generation domains. Note that initializable and variable delays work fine in the simulation domains. For example, the CGC:multirate:filterbank demo produces initializable delay warnings. The output from the CGC:multirate:filterbank demo is different than the output from the SDF:multirate:filterbank demo in that the original and reconstructed signals don't overlap as much in the CGC version. A.6.5 Bugs in pxgraph If pxgraph is given only one point to plot, nothing appears in the plot window. If pxgraph is given exceptional numeric input, such as the IEEE floating point Inf, -Inf, or NaN, then it displays a blank window only. If pxgraph is given an empty file to plot, all it does is send a message "problems with input data" to the standard output. Zooming in on bar graphs doesn't work right. There is no way to produce hardcopy without running pxgraph interactively. Specifying the colors for data sets using X resources does not work. A.6.6 HPPA specific bugs If you are rebuilding Ptolemy on the hppa, you must have X11 installed. Apparently, HP ships machines without most of the X11 include files. The CGC demo animatedLMS demo dumps core upon start-up. On the hppa, under the HP C++ compiler, Xhistogram may have rounding problems. On the hppa, the CGC animatedLMS demo requires editing of Target Parameters to compile On the hppa, the CGC animatedLMS demo gets an Arithmetic Exception and core dumps. On the hppa, the SDF animatedLMS demo generates a "non-numeric value" error in Tcl if the step size is so large that the system is made to go unstable. Compilation under older versions of hppa.cfront may fail. The problem seems to be with the +A ld command line argument. You must use the +A ld argument when compiling pigiRpc and ptcl, or incremental linking of new stars will fail. However, use of the +A argument produces the warning: CC: error: could not find __head symbol. You must use CC to link. If your main is not in C++, a call to _main() is required.(740) Even if this warning is printed, a viable binary is still produced. The +A ld argument is not necessary for other binaries, such as vem and pxgraph. If you are running an older version of the HP Cfront compiler, you may need to add -DPOSTFIX_OPT= to your c++ command line. See config-hppa.cfront.mk. If you are having problems incrementally linking in stars, and you are getting messages like: /bin/ld: (Warning) Inter-quadrant branch in XXX where XXX is the name of the .o file you are trying to link in, then you may need to be compiling your stars with the proper level of optimization. See "Dynamic linking and makefiles" on pageA-31 for more information. If, under HPUX9.x, you get a message like: ld: fatal: relocations remain against allocatable but non-writable sections Then you may need to apply a patch to ld. The patch is named PHSS_5734, and it is available from http://support.mayfield.hp.com To incrementally link new stars under HPUX9.x, you will probably need to supply a make.template file. See "Dynamic linking fails" on pageA-30. The multilink command seems to trigger Inter-quadrant branch messages, and then hang pigi. We are not sure why. HPUX10.x will build a pigiRpc with the Process Network (PN) domain, but the event loop is broken. The PN domain is not part of the default hppa build, so this problem will not affect most users. If you are under HPUX10, and you wish to build the PN domain requires Distributed Computing Environment (DCE) threads. You will need to install the DCE development set of the OS CDs. If you don't have a /usr/include/pthread.h, then you probably don't have the DCE development set installed. A.6.7 IBM AIX specific bugs Xavier Warzee suggest the following for gcc and AIX. To generate gcc-2.7.2 under AIX3.2.5 with cc, you need the PTF U436313. The PTF U432238 is suggested in the README.RS6000 file from the gcc-2.7.2 distribution, but this PTF is superseded by the PTF U436313. This PTF allows you to upgrade the cc IBM compiler from the release 1.3.0.0 (delivered with AIX 3.2.5) to the release 1.3.0.33 which compiles gcc-2.3.6. A.6.8 Silicon Graphics IRIX5 specific bugs The Silicon Graphics port is not one of our main ports, so there are several serious bugs: Linking of a full size pigiRpc binary can fail with a `GOT Overflow' message. The problem is that pigiRpc has too many symbols. The Irix dso man page suggests using shared libraries, but gcc-2.7.2 may not support C++ shared libraries under Irix. The workaround is to run ptrimRpc rather than pigiRpc. Installation of the xv man pages will fail. Irix does not have nroff and tbl. To build the CGC demos, you may need to exit pigi, set the environment variable SGI_CC to -cckr: setenv SGI_CC -cckr and restart pigi. See the sgi cc man page for more information. sdf:image:motionCompensation demo has some odd looking blocks in the McompOutput.1 image. Some of the images from the irix5 run of this demo do not look like images in the sun4 version of this demo. A.6.9 Linux specific bugs We do not have access to a Linux system on site at UC Berkeley, so our support of Linux is very limited. If you are having problems with prebuilt Linux binaries, you may want to try rebuilding Ptolemy from scratch. You may also want to check the ptolemy-hackers archives, located at the bottom of the Ptolemy home page at http://ptolemy.eecs.berkeley.edu. Linux uses GNU ar, which seems to have problems if it is run on two files whose names are not unique in the first 13 characters. We have renamed a number of stars to workaround this problem. The make checkjunk command will report the names of files that are not unique in the first 13 characters. You should only have problems with this if you are creating stars of your own and placing them in libraries. Under Linux, the CGC butterfly demo produces a butterfly.c file that has garbage characters in it, and will not compile. We are looking in to this, but we do not have a fix. If you are running the Linux version on standalone machine, then please refer to section "Mr. Ptolemy window does not come up" on pageA-18. Richard Nicholls reports that the ld with GNU binutils 2.5.2 does not support dynamic loading (See the TODO file distributed with the GNU binutils source). One solution is to use an older version of GNU ld. Another solution would be to use dlopen() style incremental linking, see $PTOLEMY/src/kernel/Linker.sysdep.h. A.6.10 Sun Solaris 2.4 specific bugs The binaries we distribute were built under Solaris2.4. We have not recently built Ptolemy under Solaris 2.3, but it might work anyway. In config-sol2.mk, we define -DPTSOL2_4 for Solaris 2.4 specific changes. If you are running Solaris2.3, you could try not defining -DPTSOL2_4 and doing a build. To build Ptolemy under Solaris2.5, set your PTARCH variable to sol2.5. If, while linking, you get a message like unable to locate archive symbol table: Format error: archive fmag then you have probably run out of swap space. See the Solaris swap command for how to add more swap with mkfile. Under Solaris 2.5 with SunSoft CC 4.1, src/kernel/MatrixParticle.cc fails to compile. The fix for this may require substantial reimplementation of the Ptolemy Matrix class, so the changes did not make it into the 0.6 release. The Utah Raster Toolkit does not come with a Solaris2.4 configuration file. We are running SunOS binaries in house. See "Other useful software packages" on pageA-16 for more information. A.6.11 Sun OS4 specific bugs If you attempt to recompile octtools under SunOS 4.1.3 with an X11R4 version of OpenWindows, you may have problems with octtools/Xpackages/iv/iv.c. See "Special considerations for use under OpenWindows" on pageA-8 for more information. If you are using the prebuilt GNU binaries in pt-0.6.gnu.sun4.tar.gz, then you may have problems if your Ptolemy distribution is not at /users/ptolemy, and you try setting the GNU environment variables with the $PTOLEMY/bin/g++-setup script. We are working towards a solution, but you might find the following variables will work for you: unsetenv GCC_EXEC_PREFIXunsetenv C_INCLUDE_PATH unsetenv CPLUS_INCLUDE_PATsetenv LIBRARY_PATH $PTOLEMY/gnu/$PTARCH/lib setenv COMPILER_PATH $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH/2.7.2 setenv GCC_INCLUDE_DIR $PTOLEMY/gnu/$PTARCH/lib/gcc-lib We are working on a solution for this. A.6.12 DEC Alpha specific bugs The DEC Alpha port is a new port that has had very little testing, so there are bound to be 64bit vs. 32bit bugs The CGC fixed-point demos give incorrect results. This is most likely due to the fact that the DEC Alpha is 64 bits. A.6.13 GNU compiler bugs If you write your own stars, then be aware that gcc-2.7.2 may not choose the expected cast. In particular, g++ has been know to cast everything to Fix if the explicit cast is omitted. The arithmetic is then performed using fixed-point computations. This will be dramatically slower than double or integer arithmetic, and may yield unexpected results. It is best to explicitly cast states to the desired form. For more information, see the ptlang chapter in the Ptolemy Programmers Manual. If you already have GNU make installed, and the binary is called gmake, then the installation of the Ptolemy GNU tools may fail. The workaround is to create a link in your path from make to gmake. A.7 Additional resources The best, most complete source for information on Ptolemy is to be found in the Ptolemy manual, The Almagest. The manual is included in every distribution and is available in our WWW and FTP sites. In addition, the printed documentation is also available from the ILP office at the following address: EECS/ERL Industrial Liaison Program Office Software Distribution 205 Cory Hall University of California at Berkeley Berkeley, CA 94720 (510) 643-6687 email: ilpsoftware@eecs.berkeley.edu A second source is the ptolemy-hackers@ptolemy.eecs.berkeley.edu mailing list. This list provides a forum for Ptolemy questions and issues. Users of the current release who have a Ptolemy question, comment, or think they've found a bug should send mail to ptolemy-hackers. Archives of the mailing list are also available. See the "Ptolemy mailing lists and the Ptolemy newsgroup" on pageA-3. A third source is the Ptolemy Usenet news group comp.soft-sys.ptolemy. A fourth source on the latest information about Ptolemy is the Ptolemy World Wide Web (WWW) server accessible by programs such as Netscape. The Universal Resource Locator (URL) for the Ptolemy WWW server is http://ptolemy.eecs.berkeley.edu. The WWW pages contain on-line access to a quick tour of Ptolemy, a list of publications, a collection of technical papers, information on the members of the development team, and links to WWW information on related tools. The WWW interface is a superset of our FTP server discussed below. Another source is the Ptolemy FTP site. To access this, use anonymous FTP to ptolemy.eecs.berkeley.edu. The directory pub/ptolemy/papers contains some of the latest Ptolemy papers and articles. A.8 Submitting a bug report Ptolemy is offered without support, but we are nonetheless interested in hearing your feedback with regard to bugs. A good bug report consists of the following elements: What OS you are running under (e.g. SunOS4.1.3, Solaris2.5.1, HPUX-10.01).a What version of Ptolemy you are running. If you are not running the latest version, you may want to upgrade and see if your bug has been fixed already. Whether you are using prebuilt binaries, or if you compiled your binaries yourself. If the problem is with the compiler, and you are using the Gnu compiler, you should also state whether you are using the prebuilt compiler we provide, or your own version. You should also try running gcc -v to see what version of the compiler you are running. It is best for us if you can reproduce the bug in a small test case and send us your ~/pigiLog.pt file, along with a detailed description of what you did and what happened. The best place to mail a bug report is to send it to the Ptolemy-hackers mailing list at ptolemy-hackers@ptolemy.eecs.berkeley.edu. If the bug consists of a problem with facets, you might want to uuencoded these facets and include them in your mail message. Note that there is a 40K size limit to mail to Ptolemy-hackers, so if your mail message is large, then you may want to send it only to ptolemy@ptolemy.eecs.berkeley.edu. To uuencode a facet and a galaxy: tar -cf /tmp/facets.tar yourfacet yourgalaxy uuencode /tmp/facets.tar facets.tar > facets.uu Then include the facets.uu file in a mail message. You may get some leverage out of compressing the facets.tar file before uuencoding it.