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
The Development Environment
Open System Services Porting Guide—520573-006
2-14
C and C++ Compilation Using the c89 Utility
Using ld or eld to Link Native Linkfiles
If you intend to create dynamic-link libraries (DLLs) or create a program that uses
DLLs, you must use the ld or eld linker to create a file consisting of position-
independent code (PIC). ld is the TNS/R native PIC linker; it runs on G-series and
H-series systems, but its output can be executed only on G-series systems. eld is the
TNS/E native PIC linker, and runs on H-series systems. The ld and eld linkers
combine compiler-generated PIC linkfiles and create necessary tables and structures
to produce a PIC loadfile. The loadfile is either a program or a DLL. Loadfiles created
by ld or eld are loaded into virtual memory for execution by the rld loader, which
works with the operating system. ld, eld, and rld can be used in the OSS and
Guardian environments.
To create a PIC linkfile when using the c89 utility, specify either the -Wcall_shared
option (creates a PIC linkable object file) or the -Wshared option (creates PIC code
and invokes either ld or eld to create a DLL, depending on whether the program is
being compiled for the TNS/R or the TNS/E platform). ld or eld links the linkfile with
any other linkfiles specified on the command line, and writes a loadfile to a specified
output file. You can also specify DLLs to be loaded with the current loadfile.
To run ld or eld from the Guardian environment, type ld or eld at the system prompt.
The ld Manual, eld Manual, and rld Manual describe how to invoke and use the ld,
eld, and rld utilities.
Using Binder for TNS Object Files
By default, the G-series c89 utility for TNS object files performs dynamic binding. In
dynamic binding, the Binder resolves references to library functions using a shared
run-time library (SRL). Final resolution of references is performed at run time.
Programs that use an SRL cannot use a user library. Dynamic binding produces
smaller program files and uses fewer system resources than static binding. Static
binding is also available with the G-series TNS c89 utility.
You can perform static binding for OSS programs. In static binding, the Binder resolves
references to library functions by binding the functions into the program. Static libraries
can be used for dynamic binding. The Binder resolves external references using all the
specified static libraries before using the SRL. An SRL is an object file that the
operating system links to program files at run time.
File Locations for c89 Files
The standard C and C++ header files, library files, and other files for native c89 and
TNS c89 are in different locations.
Note. You cannot use ld or eld on TNS interpreted or accelerated object files.