dlopenstyle dynamic linking, then the ptcl
linkcommand can be called with either a
.ofile or a
.sofile. If the
linkptcl command is passed a
.ofile, then a
.sofile will be generated. If link ptcl command is passed a
.sofile, then the
.sofile will be loaded. If the
.sofile does not exist, then an error message will be produced and the link will return. There are several ways to specify the path to a shared object.
1. Using just a file name
link foo.sowill not work unless LD_LIBRARY_PATH includes the directory where
foo.soresides. The man pages for
lddiscuss LD_LIBRARY_PATH Interestingly, using
putenv()to set LD_LIBRARY_PATH from within ptcl has no effect on the runtime loader.
2. 2If the file name begins with
./, then the current directory is searched.
link ./foo.soshould work, as will
3. If the file name is an absolute path name, then the shared object will be loaded.
link /tmp/foo.soshould work.
4. Dynamic programs can have a run path specified at link time. The run path is the path searched at runtime for shared object. (Under Solaris2.3, the
ldcontrols the run path. Under Irix5.2, the
ldcontrols the run path). If ptcl or pigiRpc has been compiled with a run path built in, and the shared object is in that path, then the shared object will be found. The Sun Linker Manual says: "To locate the shared object foo.so.1, the runtime linker will use any LD_LIBRARY_PATH definition presently in effect, followed by any runpath specified during the link-edit of prog and finally, the default location /usr/lib. If the file name had been specified ./foo.so.1, then the runtime linker would have searched for the file only in the present working directory."
Linker.h,specifying the class interface,
Linker.cc,specifying the implementation, and
Linker.sysdep.h,specifying all the machine dependent parts of the implementation. To turn on debugging, compile
Linker.ccwith the DEBUG flag defined. One way to do this would be:
cd $PTOLEMY/obj.$PTARCH/kernel; rm -f Linker.o; make OPTIMIZER=-DDEBUGThe Linker class currently uses "ld -A" style dynamic linking on the Sun4 (Sparc) running SunOS4.1 and
g++,the Sun4 (Sparc) running SunOS4.1 and Sun's
cfrontport, DECStations running Ultrix, HP-PA running
cfrontport. The Linker class currently uses "dlopen()" style dynamic linking on the Sun4 (Sparc) running Solaris2.4 and
g++,the Sun4 (Sparc) running Solaris2 and Sun's
CC-3.0),the Sun4 (Sparc) running Solaris2 and Sun's native C++ compiler
CC-4.0,and SGI Indigos running IRIX-5.2 and
g++.The intent is to structure the code in such a way that no
Linker.cc;they should all be in
new,because the right size is not known in advance but a starting location must, as a rule, be passed to the loader in advance. This means that there is a wired-in limit to how much code can be linked in. The symbol
LINK_MEMORY,which is set to one megabyte by default, is easily changed if required. Here are the steps taken by the linker to do its work:
1. Align the memory as required.
2. Form the command line and execute the Unix linker. Only certain flags in the command line will be system-dependent.
3. Read in the object file. This is heavily system-dependent.
4. Make the read-in text executable. On most systems this is a do-nothing step. On some platforms (such as HP) it is necessary to flush the instruction cache and that would be done at this point.
5. Invoke constructors in the newly read in code. Constructors are found by use of the
nmprogram; the output is parsed to search for constructor symbols, whose form depends on the compiler used.
6. If this is a permanent link, copy the linker output to file
.pt_symtable;otherwise delete it.
1. Generate a list of files to be linked in. If we have not yet done a permanent link, then the list of files to be linked in will consist of only the files in this link or multilink command. If the link is a permanent link, then we save the object name. For each successive link, we check the name of the object to be linked in against the list of objects permanently linked for duplicate file names. For each link after a permanent link, we include the names of all the unique permanently linked in objects in the generation of a temporary shared object file.
2. Generate a shared object
.sofile from all the objects to be linked in. The
.sofile is created in /tmp.
3. Do a
dlopen()on the shared object.
4. Most architectures use
nmto search for constructors, which are then invoked. Currently, sol2.cfront does not need to search for, or invoke constructors. gcc-2.5.8 has patches that allow similar functionality, but apparently these patches are not in gcc-2.6.0. Shared libraries in the SVR4 implementation contain optional
__finifunctions, called when the library is first connected to (at startup or
dlopen())and when the library is disconnected from (at
dlclose()or program exit), respectively. Some C++ implementations can arrange for these
__finifunctions to contain calls to all the global constructors or destructors. On platforms where this happens, such as sol2.cfront, there is no need for the Linker class to explicitly call the constructors, as this will happen automatically.