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
Migrating Guardian Applications to the OSS
Environment
Open System Services Porting Guide—520573-006
8-27
Predefined Preprocessor Symbols
Predefined Preprocessor Symbols
The native and TNS C compilers provide three predefined preprocessor symbols:
__TANDEM, __INT32, and __XMEM. (Note that there are two underscores at the
beginning of these preprocessor symbol names.)
You can use __TANDEM to increase the portability of your C programs. (Enclose
system-dependent source text in a #ifdef or #ifndef section to test for the
existence of __TANDEM.)
__INT32 (for int defined as 32 bits) is defined by the C compiler when the WIDE
pragma is present; __XMEM (for large memory model) is defined by the C compiler
when the XMEM pragma is present.
The TNS/R and TNS/E native C compilers also provide the _TNS_R_TARGET and
_TNS_E_TARGET predefined preprocessor symbols, respectively, which distinguish
them from the TNS C compiler.
Linking
The C run-time library routines are bound into an OSS program dynamically at run time
unless the -WBstatic option is specified, or the shared run-time library (SRL) or
dynamic-link library (DLL) cannot be found at compile time. For the native
environments, certain C run-time library routines that are bound into an OSS program
can be found in the /usr/lib directory in the following files; for the TNS environment,
these files are in the /nonnative/usr/lib directory:
The names and residence of other C libraries differ by platform. See the C/C++
Programmer’s Guide for examples of sets of libraries that you might need to specify.
The TNS/R native c89 utility invokes either nld (default) or ld for linking. nld looks
for a file with the.srl suffix (for example, libc.srl) to resolve unresolved external
references first; then it looks for a file with the.a suffix (for example, libc.a). The.a
library file is not used when the.srl library file is found. The directories are searched
in the order of /lib, /usr/lib, and then /usr/local/lib.
ld works similarly, but first looks for a file with the .so suffix, then for a file with the
.srl suffix, then for a file with the .a suffix. The directories are searched in the order of
/lib, /usr/lib, /usr/local/lib, and then /G/SYSTEM/ZDLL.
The TNS/E native c89 utility invokes eld for linking. eld searches first for a file with
the .so suffix, then for a file with the .a suffix. eld uses the same directory search
order as ld.
The TNS c89 utility looks for a file with the .so suffix (for example, libc.so) instead
of a file with the .srl suffix.
libl.a lex library routines
libyacc.a yacc library routines