Code that is linked in by the "temporary link" technique does not alter the symbol table in use. For that reason, subsequent incremental links, whether temporary or permanent, cannot "see" any code that was linked in by previous temporary links. The advantage is that the same symbols (for example, a Ptolemy star definition) may be redefined, which is useful in code development, as buggy star definitions can be replaced by valid ones without exiting Ptolemy. Code that is linked in by the "permanent link" method has the same status as code that was linked into the original executable. With "ld -A" style incremental linking, a permanent link creates or replaces the .pt_symtable file in the directory in which Ptolemy was started. This file contains the current symbol table for use by subsequent links, temporary or permanent. This file is deleted when the Ptolemy process exits normally. It is left around when the process crashes, as it is useful for debugging (as it contains symbols for object files that were incrementally linked using the permanent method as well as those in the original executable). With dlopen() style incremental linking, we keep track of all the files that have been permanently linked in. After a file has been permanently linked in, each successive link (permanent or not) includes all the permanently linking in files. That is, if we permanently link in foo.o, then when we link in bar.o, we will generate a shared object file that includes both foo.o and bar.o, and then call dlopen() on that shared object file. Note that with dlopen() style linking it is possible to relink in stars that have been permanently linked. When a file is to be linked in, we check against the list of permanently linked in file names and remove any duplicates. This method of checking will fail if one permanently links in a file, and then links in the same file as a different name, perhaps through the use of symbolic links. That is, if we permanently link in ./foo.o and ./bar.o is a link to ./foo.o, when we link in ./bar.o, we will have multiple symbols defined, and we will get an error. In other words, we only check for duplicate file names, we do not check for duplicate symbols in any files, the loader does this for us. Currently each dlopen() style link generates a temporary shared object in /tmp. If you are doing a large number of dlopen() style permanent links, you will have many files in /tmp. We hope to resolve this potential problem in a later release. Eventually, it would be nice if the code read the value of an optional environment variable, such as TMPDIR.
ptolemy@eecs.berkeley.edu
Copyright © 1990-1997, University of California. All rights
reserved.