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-13
C and C++ Compilation Using the c89 Utility
Differences in Handling Input Files
When compiling source code with the G-series TNS C compiler, the compiler assumes
the filename starting with /G/ is a Guardian file and reads its contents to determine its
type instead of checking for a suffix. The TNS/R and TNS/E native C compilers do not
read any file in this manner; they require a suffix for the input file. The G-series TNS C
compiler accepts filenames with and without the dot (.) suffix; the native C compilers
reject such names. Refer to the c89(1) reference page for acceptable suffixes for
input files.
For example, when specifying a C++ source for the G-series TNS C compiler, you can
specify the -Wcfront flag; otherwise, c89 assumes the file contains C source code.
For specifying a C++ source file for the native C compilers, one of the following C++
suffixes is required on the c89 command line, as well as the -Wplusplus flag:.ii,
.C, .cpp, .c++, or .cc.
Linking Your Program Modules
You can compile and link your application in a single operation by using the OSS c89
utility. Alternatively, you can compile program modules separately and link them using
either the ld, nld, or eld utility, or the Binder program.
Compiling and Linking With the c89 Utility
Most OSS system library routines are in /usr/lib. For linking, the library routines not
found there are typically found in the common run-time environment, or in the Guardian
environment. Other libraries can be searched using the -L flag of the c89 utility. See
File Locations for c89 Files on page 2-14; file locations are different between the native
and TNS C compilation tools.
For more information about compiling and linking files with c89, refer to the c89(1)
online reference page or the Open System Services Shell and Utilities Reference
Manual. Refer also to the C/C++ Programmer’s Guide.
Using nld to Link Native Object Files
The nld utility collects, links, and modifies code and data blocks from one or more
TNS/R native object files to produce a non-PIC executable native object file. nld can
be used in the OSS and Guardian environments.
When using native c89 to compile code, c89 invokes nld automatically for you. If no
c89 flags that prevent linking (such as -c or -E) are given, and all source files compile
without error, nld links the native object files with any libraries specified on the
command line, and an executable object file is written to an output file.
To run nld from the Guardian environment, you need to type nld at the system
prompt. The nld Manual describes how to invoke and use the nld utility.
Note. You cannot use nld or noft on TNS interpreted or accelerated object files.