Linking Shared Run-Time Libraries (Srls) - HP nld Manual

nld Utility
A program file can have at most one TNS/R native user library associated with it. The
following table shows how to associate a TNS/R native user library with a program file.
When How
Link time* nld utility -libname library option
nld utility -set libname library option
nld utility -change libname library options
Native c89 utility -Wnld= "nld-options" option
Native nmcobol utility -Wnld= "nld-options" option
Run time TACL command interpreter RUN command LIB option
OSS run command -lib option
OSS runv command -lib option
OSS run gtacl command -lib option
* library must be a Guardian file name. For details, see
When using programs or user libraries that contain C++ code, it is recommended that
you use the noft option
and the user library have compatible C++ dialects. (For information about C++ dialects,
see C++ Programs
User libraries specified at run time override those specified at link time.

Linking Shared Run-Time Libraries (SRLs)

An SRL contains code present in virtual memory at run time, to be shared by other
processes, rather than being copied into object files. An SRL can also contain global
data, and each process using the SRL automatically gets its own run-time copy of the
data, called instance data. A process can use several SRLs.
Note. nld supports TNS/R native SRLs. It does not support the TNS SRL available to TNS
and accelerated programs in the OSS environment. See the Binder Manual for details.
Some of the code configured in the system library for TNS processes is packaged in
SRLs for native processes, for example:
C run-time library
TCP/IP sockets library
Tools.h++ class library
Much of the OSS API
HP supplies public SRLs; you cannot create your own. You can create your own user
library. See Linking User Libraries
LISTATTRIBUTE or LA
on page 2-10.)
on page 2-13 for details.
nld and noft Manual—520384-003
2- 15
Linking Shared Run-Time Libraries (SRLs)
-libname on page 3-9.
on page 5-22 to verify that the program