Open System Services Porting Guide (G06.24+, H06.03+)
Table Of Contents
- What’s New in This Manual
- About This Manual
- 1 Introduction to Porting
- 2 The Development Environment
- 3 Useful Porting Tools
- 4 Interoperating Between User Environments
- Purpose of Interoperability
- The OSS User Environment
- OSS Commands for the Guardian User
- Guardian Commands for the UNIX User
- OSS Pathname and Guardian Filename Conversions
- Running the OSS Shell and Commands From TACL
- Running Guardian Commands From the OSS Shell
- Running OSS Processes With Guardian Attributes
- Using OSS Commands to Manage Guardian Objects
- 5 Interoperating Between Programming Environments
- 6 OSS Porting Considerations
- 7 Porting UNIX Applications to the OSS Environment
- 8 Migrating Guardian Applications to the OSS Environment
- General Migration Guidelines
- C Compiler Issues for Guardian Programs
- Using New and Extended Guardian Procedures
- Using OSS Functions in a Guardian Program
- Interoperating With OSS Programs
- Starting an OSS Program From the Guardian Environment
- C Compiler Considerations for OSS Programs
- Porting a Guardian Program to the OSS Environment
- How Arguments Are Passed to the C or C++ Program
- Differences in the Two Run-Time Environments
- Which Run-Time Routines Are Available
- Use of Common Run-Time Environment (CRE) Functions
- Replacing Guardian Procedure Calls With Equivalent OSS Functions
- Which IPC Mechanisms Can Be Used
- Interactions Between Guardian and OSS Functions
- 9 Porting From Specific UNIX Systems
- 10 Native Migration Overview
- 11 Porting or Migrating Sockets Applications
- 12 Porting Threaded Applications
- A Equivalent OSS and UNIX Commands for Guardian Users
- B Equivalent Guardian Commands for OSS and UNIX Users
- C Equivalent Inspect Debugging Commands for dbx Commands
- D Equivalent Native Inspect Debugging Commands for dbx Commands
- E Standard POSIX Threads Functions: Differences Between the Previous and Current Standards
- Glossary
- Index
Porting From Specific UNIX Systems
Open System Services Porting Guide—520573-006
9-5
Development Tools
•
strip removes the symbolic debugging information and symbol tables from an
object file, reducing the amount of space taken on a disk. More information about
using strip is available in the strip(1) online reference page; strip is also
available in the OSS environment.
If you manage your disk usage on the workstation using strip, then you can
manage your disk usage in the OSS environment using strip. Note that strip
should not be used in the OSS environment until all debugging work has been
completed.
Linkable Library Routines
The final phase of compiling is the linking of the object files that you have compiled
with standard library routines. There are system-standard library routines, as well as
private library routines, that you can link into your programs. Your UNIX workstation
might use a separate linker for this task, or your C compiler might provide linking
services.
The HP C compiler also provides linking services, or you can use the nld, ld, or eld
linker if you prefer.
Most UNIX C compilers support both dynamic and static linking. Dynamic linking
implies shared library objects are loaded at execution time. (Static linking includes
library modules in the executable program at compile time.) On a UNIX workstation,
the standard C library /usr/lib/libc.so is searched by default for dynamic library
modules.
The OSS environment also supports both static and dynamic linking. Static linking of
SRLs is performed by the nld utility. A dynamic linking capability is provided by the ld
utility (for TNS/R PIC object files) and the eld utility (for TNS/E object files). ld and
eld create dynamic-link libraries (DLLs), which can be loaded and unloaded by a
running process. Both the OSS and Guardian environments support the following
UNIX98 functions:
OSS and Guardian also provide the HP function dlresultcode(). See the Open
System Services Library Calls Reference Manual for detailed descriptions of these
functions.
When you request linking through the HP C compiler, the compiler, by default, tells the
nld, ld, or eld linker to search the standard C library for static and dynamic library
modules. However, if you invoke nld, ld, or eld directly, you must specifically tell it to
search the standard C library.
dlopen()
dlclose()
dlsym()
dlerror()