http://ptolemy.eecs.berkeley.edu/papers/almagest/appendixA.html. The same file should be available via anonymous ftp from ptolemy.eecs.berkeley.edu as pub/ptolemy/ptolemy0.7/TROUBLE_SHOOTING_0.7.
/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 -)
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:
pigi script is located at $PTOLEMY/bin/pigi. If that file is not present, then you need to download the Ptolemy src file, pt0.7.src.tar.gz. This file is not optional, it contains the pigi script and other files necessary to run Ptolemy.
$PTOLEMY/bin. Under csh, do:
set path = ($PTOLEMY/bin $PTOLEMY/bin.$PTARCH $path)
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`/etc/hosts (here we add the name myhostname):127.0.0.1 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:127.0.0.1 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.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
"::tycho::Oct::openFacet"
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 linestty 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./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:
/users/ptolemy, then this may be the problem./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 backslashes at the end of lines, just press Return):
setenv SHLIB_PATH {$PTOLEMY}/lib.{$PTARCH}:\
{$PTOLEMY}/octtools/lib.{$PTARCH}:\
{$PTOLEMY}/gnu/{$PTARCH}:\
{$PTOLEMY}/tcltk/itcl.{$PTARCH}/lib/itcl
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}:\
{$PTOLEMY}/tcltk/itcl.{$PTARCH}/lib/itcl
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, 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:
/users/ptolemy to the Ptolemy distribution.
$PTOLEMY/bin/itkwish is a link to a that will attempt to set your environment properly and then start the real itkwish. If you place $PTOLEMY/bin in your path before $PTOLEMY/bin.$PTARCH, then you will be running the itkwish script which might work for you.
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.
itkwish:
#!/bin/shFor further information about troubleshooting Tycho, see the
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 $*
$PTOLEMY/tycho/doc/troubleshooting.html.
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.
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 messagestar `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 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 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*.$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).pigi, in an xterm, do the following line:xrdb -load $PTOLEMY/.XresourcesThen 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:
The problem here is that the root window is a
BadValue (integer parameter out of range for operation)
Request X_QueryColors (minor code 0)
Type `y' to continue, `n' to exit, `a' to abort:TrueColor window, which causes problems with vem. As a workaround, Arnaud LaPrevote suggests starting OpenWindows withopenwin -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 http://ptolemy.eecs.berkeley.edu/ptolemy0.7/html/sparc5tcx.html. 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:
pigi. If you get an error message like:
Error: UGetFullTechDir: cannot read .Xdefaults `vem.technology':then try starting up another X client such as
UserMain: OpenPaletteInit() failed
xclock before starting up pigi.
vem Edit-Label widget. If you see messages like
A Fatal Xt Toolkit Error has occurred:then the solution is to upgrade to XFree86 3.2.
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):
#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 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.
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.
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.2 sun4 collector might be at $PTOLEMY/gnu/sun4/lib/gcc-lib/sun4/2.7.2.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
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.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 = gccIf 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-tempsIf the collector is getting an old version of GNU
nm, then you could have problems. Passing the collector the -debug flag might help here.
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
/users/ptolemy.
setenv GCC_EXEC_PREFIX $PTOLEMY/gnu/$PTARCH/lib/\
gcc-lib/$PTARCH/2.7.2.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/libSee 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.-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.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 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-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.-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.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). 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:
compilerCommand to a compiler that you have.
$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
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).
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:
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 variablesetenv 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.x, the bundled C compiler is not ANSI compliant so it may fail to compile some CGC Universes.
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.
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.7.../../mk/stars.mk:113: *** 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-2.7.2.2 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/2.7.2.2/specs
gcc version 2.7.2.2
cxh@kahn 33% ls /users/ptolemy/gnu/sol2.5/lib/libg++.so*
/users/ptolemy/gnu/sol2.5/lib/libg++.so@
/users/ptolemy/gnu/sol2.5/lib/libg++.so.2.7.2*
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 libg++.so and libstdc++.so. Under HPUX10.x, these libraries are named libg++.sl and libstdc++.sl. A common problem is that the proper version of gcc is installed, but only the static libraries were built.ld: fatal: relocations remain against allocatable but non-writableThe fix is to configure gcc and libg++ with --enable-shared and build the shared libraries or to download the prebuilt Gnu binaries. See ftp://ptolemy.eecs.berkeley.edu/pub/ptolemy/ptolemy0.7/html/g++shared.txt 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 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.make from $PTOLEMY, rather than $PTOLEMY/obj.$PTARCH.pigiRpc. $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"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-2.7.2.2 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:
gcc-2.7.2.2/libg++-2.7.2) 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 known to have serious bugs, so you may want to upgrade. For more information, see
"Gnu Installation" on page A-7.
/users/ptolemy, or you are setting the GNU environment variables in $PTOLEMY/bin/g++-setup. Again, see the GNU Installation section.
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.
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 <stream.h>
main(){ cout << "Hello, Ptolemy.\n";}
pigiRpc and ptcl binaries that have been compiled with -O2, so you may want to compile your star with -O2.
collect2: ld returned 1 exit status
/bin/ld: Invalid loader fixup needed
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. 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 compile 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.
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
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.oTo load in multiple stars, you may find the
mv a.out SDFWirelessChannel.o
ptcl multilink command useful.
pigi -debugthe 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.
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:
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.
DE simulation can have certain inherently high cost, so using SDF or DE with SDF functionality inside wormholes can greatly improve performance.
top (ftp://eecs.nwu.edu/pub/top). You might also find it useful to use iostat to see if you are paging or swapping.
ptcl, which does not have Tk or Higher Order Function (HOF) stars. See
"Some hints on advanced uses of ptcl with pigi" on page 3-19 for details.