Hewlett-Packard Porting Guide Porting Guide

Tru64 UNIX
Tru64 UNIX to HP-UX 11i Porting Guide
For PA-RISC and Itanium®–based Systems
May 2005, Edition 5
Operating System and Version: HP-UX 11i v2
This guide presents information about porting applications from Tru64 UNIX to HP-UX 11i.
Information on porting to HP-UX 11i on both PA-RISC-based and Itanium®-based systems is
included.
Hewlett-Packard Company
Palo Alto, California
© 2005 Hewlett-Packard Development Company, L.P.
BSD® is a registered trademark of Wind River Systems, Inc.
EMANATE® is a registered trademark of SNMP Research International, Inc.
GNU™ is a trademark of the Free Software Foundation.
Intel®, Intel Inside logo, Itanium®, Itanium® 2, and Itanium®-based are trademarks or registered trademarks
of Intel Corporation in the U.S. and other countries.
Java® and Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc.
in the U.S. and other countries.
Linux™ is a trademark of Linus Torvalds.
Motif®, OSF/1®, UNIX®, X Window System™, X/Open® and The Open Group™ are trademarks or registered
trademarks of The Open Group.
Microsoft®, Visual Studio®, and Visual C++® are registered trademarks of Microsoft Corporation in the United
States and/or other countries.
Netscape® and the Netscape N and Ship’s Wheel logos are registered trademarks of Netscape Communications
Corporation in the U.S. and other countries. Netscape FastTrack/Enterprise, Netscape Directory Server, Netscape
Collaboration Server, and Netscape Mail Server are also trademarks of Netscape Communications Corporation
and may be registered outside the U.S.
OpenGL® is a registered trademark of Silicon Graphics, Inc.
Oracle® is a registered trademark, and Oracle8™, Oracle9i™, and Oracle Financials® are trademarks or registered
trademarks of Oracle Corporation.
POSIX® and IEEE® are registered trademarks of the Institute of Electrical and Electronic Engineers, Inc.
VERITAS™, the VERITAS logo, and VERITAS Storage Foundation™ are trademarks or registered trademarks of
VERITAS Software Corporation or its affiliates in the U.S. and other countries.
All other product names mentioned herein may be trademarks of their respective owners.
Proprietary computer software. Valid license from HP and/or its subsidiaries required for possession, use,
or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Neither HP nor any of its subsidiaries shall be liable for technical or editorial errors or omissions contained herein.
The information is provided “as is” without warranty of any kind and is subject to change without notice. The
warranties for HP products are set forth in the express limited warranty statements accompanying such products.
Nothing herein should be construed as constituting an additional warranty.
Contents
About This Guide
1 Porting Overview
1.1
1.2
1.3
1.4
Porting Process .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Operating System Version Identification .. ... .. ... ... .. ... .. ... ... .. ... ..
Porting and Coding Practices ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Porting Services . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
1–2
1–2
1–3
1–3
2 Porting Effort and Considerations
2.1
2.1.1
2.1.2
2.1.3
2.2
2.3
2.4
2.5
2.5.1
2.5.2
2.5.3
2.5.4
2.5.5
2.6
2.7
2.8
2.9
2.10
Tru64 UNIX to HP-UX Application Transition Tools .. ... .. ... ... .. ... ..
binaryScan .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX to HP-UX Software Transition Kit .. ... .. ... ... .. ... ..
Tru64 UNIX Migration Environment for HP-UX . ... .. ... ... .. ... ..
Third-Party Software and Tools ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Scripts . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Build Environment .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiling the Software .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Languages ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Porting Pitfalls .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Developing 64-Bit Applications . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Developing 32-Bit Applications . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
The 32-Bit Versus 64-Bit Choice ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Testing and Test Scripts . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Debugging .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Optimization .. ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Packaging and Distribution .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
2–1
2–1
2–1
2–2
2–3
2–3
2–3
2–4
2–4
2–4
2–5
2–5
2–5
2–6
2–6
2–6
2–6
2–7
3 HP-UX 11i Development Environment
3.1
3.2
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.4
3.4.1
3.5
3.6
Standards Comparisons . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
System V Habitat . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiler Overview .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiler Licensing .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP aC++ and HP ANSI C Compilers .. ... .. ... ... .. ... .. ... ... .. ... ..
HP C/ANSI C Developer’s Bundle . .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Java 2 Platform . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
FORTRAN ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
COBOL ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Location of Files and Utilities .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
System Libraries ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Patches for HP-UX 11i . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
3–1
3–1
3–2
3–2
3–3
3–3
3–3
3–4
3–4
3–5
3–5
3–6
3–7
4 Compilers
4.1
C Compilers ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Contents
4–1
iii
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.1.6.1
4.1.6.2
4.1.6.3
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.3
4.3.1
4.4
4.4.1
4.4.2
4.5
4.6
4.6.1
4.6.2
4.6.3
4.6.4
4.7
4.8
Language Differences .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Language Mode Options . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
C Compiler Options .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Preprocessor Macros . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Optimization .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Known Issues with Porting K&R C Code .. ... ... .. ... .. ... ... .. ... ..
Calling Functions without Prototypes . ... ... .. ... .. ... ... .. ... ..
Passing Types Smaller Than Expected ... ... .. ... .. ... ... .. ... ..
Negative Floating-Point to Unsigned Integer Conversion .. ..
C++ Compilers .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Language Differences .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
C++ Compiler Options .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Preprocessor Macros . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiling C Source Files ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Template Instantiation . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
typename Keyword .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Java .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Java Tuning Information ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
FORTRAN Compilers .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Language Differences .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
FORTRAN Compiler Options . .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Assembler .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Mixed-Language Programming . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
FORTRAN Trailing Underscores .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiling Mixed-Language Programs ... .. ... ... .. ... .. ... ... .. ... ..
Linking Mixed-Language Programs ... ... .. ... ... .. ... .. ... ... .. ... ..
Directives for Mixed-Language Calls .. ... .. ... ... .. ... .. ... ... .. ... ..
Controlling Namespaces . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
4–1
4–1
4–2
4–3
4–3
4–4
4–4
4–5
4–8
4–8
4–8
4–10
4–11
4–11
4–11
4–12
4–12
4–13
4–13
4–13
4–14
4–14
4–15
4–15
4–15
4–15
4–15
4–16
4–17
5 Linkers and Loaders
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
5.1.9
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8
5.2.9
5.3
5.3.1
iv
Contents
Link Editor . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX Migration Environment for HP-UX . ... .. ... ... .. ... ..
Passing Options To The Linker . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Environment Variables . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Command-Line Options .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Library Search Order ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Linker-Defined Symbols . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Weak Symbol Support .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Uninitialized Global Data .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Linker Optimizations ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Run-Time Linking ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Library Resolution . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Address Space Layout .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Adaptive Address Space .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Symbol Resolution . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Symbol Binding .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Symbol Precedence . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Environment Variables . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Loader Options .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Loader APIs . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Linker-Related Tools ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
ldd . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
5–1
5–1
5–2
5–3
5–3
5–3
5–4
5–7
5–7
5–9
5–10
5–11
5–13
5–19
5–21
5–23
5–23
5–24
5–24
5–25
5–26
5–26
5.3.2
5.3.3
5.3.4
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.5
5.6
chatr .. .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
elfdump ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
odump .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Linker Errors . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Finding Which Library . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Mismatched Data ABI .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Mismatched ABI ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Mismatched Machine Types ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Recommended Linker Options .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
5–26
5–27
5–27
5–27
5–27
5–27
5–28
5–28
5–28
5–29
6 Other Development Tools
6.1
6.1.1
6.1.2
6.1.3
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.4
6.4.1
6.4.2
6.4.3
6.4.4
6.4.5
6.4.6
6.4.7
6.4.8
Makefiles . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparing the Tru64 UNIX and HP-UX 11i Makefiles .. ... .. ... ..
Options for the make Command .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Implementing make Rules .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Debugging Tools . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Locating Debug Information .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Debugging Shared Libraries .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
User-Defined Alias . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
The Command Set . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Program Profiling Tools .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Standard UNIX Profiling Tools . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
System Timers ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Prospect Performance Tool . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP Caliper .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Memory Leak Detection and Debugging . .. ... ... .. ... .. ... ... .. ... ..
System Profiling Tools . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
top . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
vmstat .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
iostat . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
ps .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
sar . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
netstat . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
lsof . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP Glance ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
6–1
6–1
6–2
6–2
6–3
6–4
6–4
6–5
6–5
6–5
6–6
6–6
6–6
6–7
6–7
6–8
6–8
6–9
6–10
6–10
6–10
6–11
6–12
6–12
7 Run-Time Environment
7.1
7.2
7.3
7.4
7.5
7.6
7.6.1
7.6.2
7.6.3
7.6.4
7.6.4.1
7.6.4.2
7.6.4.3
7.6.4.4
Environment Variables .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Process Limits ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Run-Time Limits .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Permissions and umask .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Users and Groups . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Signals and Exceptions .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Signals . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Structured Exceptions .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Alignment Faults .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Floating-Point Exceptions .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
+FP Compiler Option ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
+fp_exception HP Fortran Option . ... .. ... ... .. ... .. ... ... .. ... ..
fesettrapenable Function .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
User Handling of FP Exceptions ... ... .. ... ... .. ... .. ... ... .. ... ..
7–1
7–2
7–3
7–4
7–4
7–5
7–5
7–5
7–5
7–7
7–8
7–9
7–10
7–10
Contents
v
Detecting Exceptions without Enabling Traps ... .. ... ... .. ... ..
7–10
Overview . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Standard POSIX 1003.1c interfaces ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Nonportable Thread Interfaces . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Thread Scheduling . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX Threading Model .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
The MxN Threading Model on HP-UX . ... .. ... ... .. ... .. ... ... .. ... ..
Thread Synchronization Methods . .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Porting Applications with Read-Write Locks . .. ... ... .. ... .. ... ... .. ... ..
Compiling and Building Multithreaded Applications . ... .. ... ... .. ... ..
Compiler Switches . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Thread Header Files ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Shared Libraries . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Thread-Safe Libraries . .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Thread Local Storage ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Thread Debugging .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP Caliper Performance Analyzer .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Visual Threads Performance Analyzer .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Alternative Scheduling Algorithm .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
8–1
8–1
8–2
8–4
8–5
8–6
8–6
8–7
8–7
8–7
8–7
8–7
8–8
8–8
8–9
8–10
8–10
8–10
8–11
7.6.4.5
8 Threads
8.1
8.2
8.3
8.4
8.4.1
8.4.2
8.5
8.6
8.7
8.7.1
8.7.2
8.7.3
8.7.4
8.8
8.9
8.10
8.11
8.12
8.13
9 Multiprocessor Environments
9.1
9.1.1
9.1.2
9.1.3
9.2
9.2.1
9.2.2
9.2.3
9.3
9.3.1
9.3.2
9.4
10
OpenMP .. .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiler Options .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Environment Variables . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX Implementation-Specific Behavior .. ... .. ... ... .. ... ..
MPI .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compaq MPI .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP MPI for HP-UX 11i . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Porting Considerations . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Processor Sets ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Processor Set Commands ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Processor Set APIs . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Clustering Considerations
10.1
HP Serviceguard .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.1
Cluster Monitoring . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.2
Enterprise Cluster Master Toolkit .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.3
Integrated Solutions . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.4
Serviceguard Extension for SAP R/3 ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.5
Serviceguard Extension for RAC .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.6
Serviceguard NFS Toolkit .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.7
Serviceguard Manager . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.1.8
Cluster Lock Disk and Quorum Service .. .. ... ... .. ... .. ... ... .. ... ..
10.1.9
Geographically Dispersed Cluster Solutions .. ... .. ... .. ... ... .. ... ..
10.2
Comparison of TruCluster Server to HP Serviceguard .. .. ... ... .. ... ..
10.2.1
Feature Set Comparison . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.2.2
Cluster File System and Single-System Image .. .. ... .. ... ... .. ... ..
10.2.3
Cluster Interconnects ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
vi
9–1
9–1
9–2
9–2
9–2
9–3
9–3
9–4
9–5
9–5
9–6
9–7
Contents
10–1
10–2
10–3
10–3
10–3
10–3
10–4
10–4
10–5
10–5
10–6
10–6
10–6
10–7
10.2.4
High-Availability Agents . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
10.3
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11
Hardware Considerations
11.1
Itanium® Processor Family Overview . .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.2
PA-RISC Processor Family Overview .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.3
Defining a “word” . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.4
Data Alignment . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.5
Determining Processors and Configurations . .. ... ... .. ... .. ... ... .. ... ..
11.6
Determining the Current Processor . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.7
Instruction Pointer (Program Counter) . ... ... .. ... ... .. ... .. ... ... .. ... ..
11.8
Processor Interval Time Counter .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.9
Application Stack . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.10 Register Stack ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.11 Floating Point ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.12 Pagesize Considerations . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.13 Atomic Memory Operations .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.13.1
High-Level Language Support .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.13.2
Assembly Spinlocks for PA-RISC .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11.13.3
Assembly Spinlocks for the Itanium® Processor Family . ... .. ... ..
11.14 References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
12
11–1
11–2
11–2
11–2
11–3
11–6
11–7
11–7
11–9
11–9
11–9
11–12
11–12
11–13
11–13
11–14
11–15
Endianism Considerations
12.1
12.2
12.2.1
12.2.2
12.2.3
12.3
12.4
12.5
12.6
12.7
12.8
12.9
13
10–8
10–9
Overview . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Persistent Data .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Preprocessor Controlled Byte Order ... ... .. ... ... .. ... .. ... ... .. ... ..
Run-Time Byte Order Control .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Using Standard Byte Order APIs .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Byte Swapping .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Unused Bytes . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Unions . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Initializing Multiword Entities in 32-Bit Chunks ... .. ... .. ... ... .. ... ..
Hex Constants Used as Byte Arrays ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Other Considerations .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Conclusion . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
12–1
12–2
12–3
12–3
12–4
12–5
12–6
12–7
12–7
12–8
12–8
12–8
Libraries and APIs
13.1
APIs .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.1
Tru64 UNIX Migration Libraries .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.2
Library Comparison . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.3
Memory Management .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.4
String Manipulation . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.5
Process Tracing .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.6
Message Catalogs .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.7
Process Management ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.8
System Information .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.9
Files and File Handles . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.10
File System Entries .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.1.11
Error Messages .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2
Dynamic Library Loading .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.1
dladdr .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13–1
13–2
13–2
13–3
13–4
13–4
13–4
13–4
13–5
13–5
13–6
13–6
13–6
13–6
Contents
vii
13.2.2
dlget .. .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.3
dlgetmodinfo .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.4
dlgetname ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.5
dlmodadd . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.6
dlmodinfo . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.7
dlmodremove .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.8
dlopen .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.9
dlsym . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.2.10
Thread Local Storage ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3
Developing Libraries ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3.1
Versioning Shared Libraries ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3.2
Dependencies . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3.3
Library Permissions . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3.4
Support for Weak Symbols .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3.5
The init/fini Routines ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3.5.1
Execution Order . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
13.3.5.2
init/fini Usage .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
14
Graphics Issues
14.1
14.1.1
14.1.2
14.2
14.3
14.4
14.4.1
14.4.2
14.5
14.6
15
Compiling and Linking X Window System Applications . .. ... ... .. ... ..
Required Include Files . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Required Libraries . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Run-Time Considerations .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
CDE Applications and Itanium® .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiling and Linking OpenGL Applications . ... ... .. ... .. ... ... .. ... ..
Required Include Files . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Required Libraries . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Java3D ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Resources . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
14–1
14–1
14–1
14–2
14–2
14–2
14–2
14–3
14–3
14–3
Networking
15.1
SNMP Agents ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2
Sockets . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
accept .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.1
15.2.2
bind ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
connect . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.3
15.2.4
listen . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
getpeername .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.5
15.2.6
getsockname .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.7
getsockopt ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.8
recv, recvfrom, recvmsg .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.9
send .. .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.10
sendto, sendmsg . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.11
setsockopt ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.12
shutdown . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.13
socket .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.2.14
socketpair ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.3
STREAMS .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
getmsg, getpmsg . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.3.1
open .. .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.3.2
putmsg, putpmsg ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.3.3
15.3.4
select . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
viii
13–7
13–7
13–7
13–7
13–8
13–8
13–8
13–9
13–9
13–10
13–10
13–11
13–11
13–11
13–12
13–13
13–13
Contents
15–1
15–1
15–2
15–2
15–3
15–4
15–4
15–4
15–4
15–5
15–5
15–5
15–6
15–7
15–7
15–7
15–7
15–8
15–8
15–8
15–8
15.3.5
streamio, ioctl . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.4
Other Network Differences . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
15.5
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
16
Security
16.1
Moving from SIA on Tru64 UNIX to PAM on HP-UX 11i .. ... ... .. ... ..
16.1.1
Tru64 UNIX SIA Overview . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
16.1.2
HP-UX 11i PAM Overview .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
16.1.3
Differences Between SIA and PAM . ... ... .. ... ... .. ... .. ... ... .. ... ..
16.1.4
PAM Data Processing Capabilities .. ... ... .. ... ... .. ... .. ... ... .. ... ..
16.1.5
API Comparison — SIA and PAM Similarities .. .. ... .. ... ... .. ... ..
16.1.6
API Comparison — SIA and PAM Mechanism Similarities .. ... ..
16.1.7
API Comparison — APIs That Are Unique to PAM . .. ... ... .. ... ..
17
Encoding Methods ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Input Methods ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Japanese Input .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Simplified Chinese . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Traditional Chinese .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Korean . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Codeset Converters .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Locales . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Message Catalogs . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
APIs for Curses Applications . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
X/Xt/Motif Applications .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
References .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Loadable Kernel Modules ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
18–1
Freeware, Open Source, Public Domain Software
19.1
HP Provided Software .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
19.1.1
Technical Computing Open Source Product ... ... .. ... .. ... ... .. ... ..
19.1.2
HP-UX Internet Express . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
19.1.3
Ximian GNOME . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
19.1.4
Mozilla . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
19.1.5
Cross-Reference for OSSC .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
19.2
Application Archives ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
19.3
Building Portable Software .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
20
17–1
17–2
17–2
17–3
17–3
17–4
17–4
17–4
17–5
17–5
17–5
17–6
Kernel and Driver Interfaces
18.1
19
16–1
16–1
16–2
16–3
16–4
16–5
16–6
16–7
Internationalization Support
17.1
17.2
17.2.1
17.2.2
17.2.3
17.2.4
17.3
17.4
17.5
17.6
17.7
17.8
18
15–9
15–9
15–9
19–1
19–1
19–1
19–2
19–3
19–3
19–4
19–5
Additional Resources
20.1
20.2
20.3
20.4
20.5
Software Resources .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Corporate Web Sites . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
User Groups and Other Sites ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Newsgroups ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Mailing Lists .. ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
20–1
20–1
20–2
20–2
20–3
Contents
ix
A
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
B
Comparison of Compaq C++ and HP aC++ Compiler Options
C
Comparison of Compaq Fortran and HP Fortran Compiler Options
D
Comparison of the Tru64 UNIX and HP-UX 11i Linker Options
E Supported Locales
F
System Tuning Information
G Porting Checklist
H
Source Code for Examples
Index
Tru64 UNIX Documentation Reader’s Comments
Examples
4–1
4–2
4–3
4–4
4–5
4–6
4–7
4–8
4–9
4–10
4–11
4–12
4–13
4–14
4–15
4–16
4–17
4–18
5–1
7–1
7–2
7–3
8–1
x
Contents
Using the Migration Environment cc Driver with -port_info_only on
PA-RISC Platform ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Using the Migration Environment cc Driver with -port_info_only on
Itanium®-based Platform ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Calling Functions without Prototypes on HP-UX 11i . ... .. ... ... .. ... ..
Using the -warnprotos Option on Tru64 UNIX . ... ... .. ... .. ... ... .. ... ..
Passing Types Smaller Than Expected .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Arguments Passed in Memory .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Arguments not Sign Extended .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Negative Floating-Point to Unsigned Integer Conversion . ... ... .. ... ..
Conversion Output on PA-RISC Matches Tru64 UNIX .. .. ... ... .. ... ..
Conversion Output on Itanium®-based Systems . ... .. ... .. ... ... .. ... ..
<iostream.h> Replaced By <iostream> .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Scoping Rules for Variables in a for Statement ... ... .. ... .. ... ... .. ... ..
Template Instantiation with a Pragma Directive . ... .. ... .. ... ... .. ... ..
Standard Template Instantiation Syntax .. ... .. ... ... .. ... .. ... ... .. ... ..
typename Keyword .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiling Mixed-Language Programs on PA-RISC . .. ... .. ... ... .. ... ..
Compiling Mixed-Language Programs on the Itanium® Processor
Family . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Define Namespace with -Aa Option on HP-UX 11i .. .. ... .. ... ... .. ... ..
Uninitialized Global Data .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Creating a Locked Account . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Unaligned Data Access . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Unaligned Access on HP-UX 11i .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Using SCHED_NOAGE Scheduler .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
4–2
4–2
4–5
4–5
4–6
4–7
4–7
4–8
4–8
4–8
4–9
4–10
4–12
4–12
4–12
4–15
4–15
4–16
5–8
7–4
7–6
7–7
8–11
11–1
11–2
11–3
11–4
11–5
11–6
11–7
11–8
12–1
12–2
12–3
12–4
12–5
12–6
12–7
12–8
12–9
12–10
12–11
13–1
13–2
13–3
13–4
13–5
13–6
13–7
13–8
13–9
Identifying the CPU From the Shell ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Determining Processor Type Using C .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Number of CPUs Using C .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Collecting System Information in C . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Determining the Current CPU . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Reading the ITC . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
PA-RISC Spinlocks in Assembly Language ... .. ... ... .. ... .. ... ... .. ... ..
Spinlock Code for Itanium® Processors .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Binary Representation of 1025 . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Supporting Multiple Byte Orderings Using The Preprocessor .. .. ... ..
Testing Byte Order .. ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Using the htons Routine . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Using the htonl Routine . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
64-Bit Host To Network Implementation .. ... .. ... ... .. ... .. ... ... .. ... ..
32-Bit Endian Byte Swap Macro .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
64-Bit Endian Byte Swap Macro .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Direct Byte Access ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Named Bit Fields . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Endianism and Unions . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Library-Level Versioning ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Library-Level Versioning For Multiple Version Support . .. ... ... .. ... ..
Weak Function Binding Using ASM ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
lib1.c Listing .. ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
lib2.c Listing .. ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
lib3.c Listing .. ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Building init/fini Sample ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Sample Run Order 1 . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Sample Run Order 2 . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11–3
11–3
11–5
11–5
11–6
11–7
11–13
11–14
12–2
12–3
12–4
12–4
12–4
12–5
12–5
12–6
12–6
12–6
12–7
13–10
13–10
13–12
13–13
13–14
13–14
13–14
13–15
13–15
Namespaces ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX 64-Bit Layout . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX 32-Bit Layout . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
64-Bit Itanium® Application Layout ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
64-Bit PA-RISC Application Layout ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
32-Bit Itanium® Application Layout ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
32-Bit PA-RISC Application Layout ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
32-Bit MPAS Application Layout .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
64-Bit MPAS Application Layout .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Library Dependencies .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
CPUID[3] Bit Positions .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Big-Endian Byte Ordering .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Little-Endian Byte Ordering . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
4–17
5–14
5–15
5–16
5–17
5–18
5–19
5–20
5–21
5–22
11–4
12–1
12–1
HP-UX 11i Release Names and Identifiers ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX Release Names and Identifiers . .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX and HP-UX 11i Standards Comparison . ... .. ... ... .. ... ..
HP-UX 11i Compilers .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Header File Paths ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
64-Bit Itanium® Library Paths . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
32-Bit Itanium® Library Paths . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
1–2
1–3
3–1
3–2
3–5
3–5
3–6
Figures
4–1
5–1
5–2
5–3
5–4
5–5
5–6
5–7
5–8
5–9
11–1
12–1
12–2
Tables
1–1
1–2
3–1
3–2
3–3
3–4
3–5
Contents
xi
3–6
3–7
4–1
4–2
4–3
4–4
4–5
4–6
5–1
5–2
5–3
5–4
5–5
5–6
5–7
5–8
5–9
5–10
5–11
5–12
6–1
6–2
6–3
6–4
6–5
6–6
6–7
6–8
6–9
6–10
6–11
7–1
7–2
7–3
7–4
8–1
8–2
8–3
8–4
8–5
8–6
8–7
9–1
9–2
9–3
9–4
9–5
10–1
10–2
10–3
11–1
11–2
11–3
xii
Contents
64-Bit PA-RISC Library Paths .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
32-Bit PA-RISC Library Paths .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
C Language Mode Options . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
C Preprocessor Macros . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
C Compiler Optimization Levels and Descriptions .. .. ... .. ... ... .. ... ..
C++ Options to Select iostreams Library .. ... .. ... ... .. ... .. ... ... .. ... ..
C++ Preprocessor Macros ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Compiler Definitions for Industry Standards .. ... ... .. ... .. ... ... .. ... ..
Library Search Paths ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Common Linker-Defined Symbols .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Common HP-UX Symbols .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Linker-Defined ELF Symbols ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Linker-Defined SOM Symbols .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Unavailable Tru64 UNIX Symbols .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Linker Optimization Options ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Depth-First Search Orders . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP-UX 11i Loader Options . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX rld_new_interface() Replacements .. ... .. ... .. ... ... .. ... ..
Tru64 UNIX ldr_* Replacements .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Common elfdump Commands ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Default Makefiles . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
make Options Differences .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of Default .SUFFIX Rules .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Program Profiling Tools .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
System Profiling Tools . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of top Options . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of vmstat Options .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of iostat Options ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Some Common ps Examples . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of sar Options . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of netstat Options . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP-UX 11i Default Process Resource Limits . .. ... ... .. ... .. ... ... .. ... ..
Tru64 UNIX Default Process Resource Limits . ... ... .. ... .. ... ... .. ... ..
Default Run-Time Limits ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
+FP Option Arguments .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Thread Attribute Default Values ... ... .. ... ... .. ... .. ... ... .. ... ..
Nonportable POSIX Thread Interfaces .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Single UNIX Standard v2 Threads APIs ... ... .. ... ... .. ... .. ... ... .. ... ..
Nonportable POSIX Thread Interfaces Available in the Tru64 UNIX
Migration Environment for HP-UX . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Threads Header Files ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Shared Libraries . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Debugger Commands ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
OpenMP Directives and Optimization Levels .. ... ... .. ... .. ... ... .. ... ..
HP MPI Paths on HP-UX ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
HP MPI Commands for HP-UX . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Processor Set Commands ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Processor Set APIs ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Feature Set Comparison . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Supported Cluster Interconnect Technologies .. ... ... .. ... .. ... ... .. ... ..
High-Availability Agents (Scripts) for Third-Party Applications . ... ..
Multi-byte Element Terminology .. .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
_SC_CPU_VERSION Values . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Parameters for Additional Processor Information ... .. ... .. ... ... .. ... ..
3–6
3–6
4–1
4–3
4–4
4–9
4–11
4–16
5–3
5–5
5–5
5–5
5–6
5–7
5–10
5–22
5–24
5–25
5–25
5–27
6–2
6–2
6–3
6–5
6–8
6–8
6–9
6–10
6–10
6–11
6–11
7–2
7–3
7–3
7–8
8–1
8–2
8–3
8–3
8–7
8–8
8–9
9–1
9–4
9–4
9–5
9–6
10–6
10–8
10–8
11–2
11–3
11–4
11–4
13–1
13–2
15–1
15–2
16–1
16–2
16–3
17–1
17–2
17–3
17–4
17–5
18–1
18–2
18–3
19–1
19–2
19–3
19–4
A–1
B–1
C–1
D–1
E–1
F–1
H–1
Architecture Supported Pagesizes .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
System APIs Library Availability . .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
POSIX Nonblocking I/O .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Summary of Socket API Comparison .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Summary of STREAMS API Comparison .. ... .. ... ... .. ... .. ... ... .. ... ..
SIA and PAM Application API Similarities ... .. ... ... .. ... .. ... ... .. ... ..
SIA and PAM Mechanism API Similarities ... .. ... ... .. ... .. ... ... .. ... ..
PAM APIs that do not have SIA equivalents . .. ... ... .. ... .. ... ... .. ... ..
Table 17–1: Encoding Methods . ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Japanese Input Support Comparison .. .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Simplified Chinese Input Support Comparison ... ... .. ... .. ... ... .. ... ..
Traditional Chinese Input Support Comparison .. ... .. ... .. ... ... .. ... ..
Korean Input Support Comparison . ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Kernel Loadable Module Commands: HP-UX 11i v1.6 and Earlier . ..
Kernel Loadable Module Commands: HP-UX 11i v2 and Later .. ... ..
Kernel Loadable Module APIs .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Technical Computing Open Source Applications .. ... .. ... .. ... ... .. ... ..
Non-OE Open Source Components .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
OE Open Source Components ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Freeware Status and Availability . .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of Compaq C and HP C and HP ANSI C Compiler
Options ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Comparison of Compaq C++ and HP aC++ Compiler Options .. .. ... ..
Comparison of Compaq Fortran and HP Fortran Compiler Options .
Comparision of the Tru64 UNIX and HP-UX 11i Linker Options ... ..
Supported Locales ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
System Tuning Options .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
Examples . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... ..
11–12
13–2
13–6
15–2
15–8
16–5
16–6
16–7
17–1
17–2
17–3
17–3
17–4
18–1
18–1
18–2
19–1
19–2
19–2
19–3
Contents
A–1
B–1
C–1
D–1
E–1
F–1
H–1
xiii
About This Guide
This guide provides information and hints on porting from Tru64 UNIX to HP-UX
11i. We recommend Chapter 3, HP-UX 11i Development Environment for all
developers and key decision-makers in your organization. The remaining chapters
provide in-depth technical information pertaining to specific areas of porting.
The primary focus of this guide is the migration of applications from Tru64 UNIX
Version 5.1B to HP-UX 11i v2; however, information is provided on other release
versions where differences exist. Throughout this guide, whenever HP-UX 11i
is referred to without any qualifying version number it will refer to the current
release on both PA-RISC and Itanium®-based platforms.
HP has developed this guide to help you take advantage of open systems and
multiplatform environments. Technical updates and errata are published in the
Technical Update for Tru64 UNIX to HP-UX 11i Porting Guide available from:
http://www.hp.com/go/application-transition
Audience
This guide is for developers who need to migrate applications from Tru64 UNIX
to HP-UX 11i and assumes that you have software development experience on
Tru64 UNIX.
This document is available from the application transition Web site:
http://www.hp.com/go/application-transition
Additional transition tools are available from the Tru64 UNIX to HP-UX 11i
application transition Web site:
http://www.hp.com/go/tru64appmigration
Organization
This guide is organized as follows:
Chapter 1
Summarizes the porting process.
Chapter 2
Provides information to assess the porting effort.
Chapter 3
Describes the development environment under HP-UX 11i.
Chapter 4
Discusses differences in the compilers.
Chapter 5
Discusses differences in the linker and loader.
Chapter 6
Discusses other development tools useful in the porting effort.
Chapter 7
Discusses differences in the run-time environments.
Chapter 8
Discusses information on porting multithreaded applications.
Chapter 9
Discusses OpenMP, MPI, and other multiprocessor-specific
development models.
Chapter 10
Discusses cluster-aware application development.
Chapter 11
Discusses hardware-specific topics.
Chapter 12
Discusses differences in data storage between big- and
little-endian systems.
About This Guide
xv
Chapter 13
Discusses differences in the system libraries, APIs, and
development of libraries.
Chapter 14
Discusses graphics development.
Chapter 15
Discusses network application development differences.
Chapter 16
Discusses security application development differences.
Chapter 17
Discusses differences in the internationalization (I18N) and
localization (L10N) interfaces.
Chapter 18
Discusses kernel driver development.
Chapter 19
Provides pointers to available Freeware, Public Domain, and
Open Source solutions.
Chapter 20
Lists additional porting resources.
Appendix A
Provides a complete mapping of Compaq C to HP ANSI C
options.
Appendix B
Provides a complete mapping of Compaq C++ to HP aC++
options.
Appendix C
Provides a complete mapping of Compaq Fortran to HP Fortran
options.
Appendix D
Provides a complete mapping of Tru64 UNIX linker to HP-UX
11i linker options.
Appendix E
Provides a complete list of supported locales on Tru64 UNIX
and HP-UX 11i.
Appendix F
Provides some minimal tuning information for HP-UX 11i.
Appendix G
Provides a checklist of some basic porting information.
Appendix H
Lists all of the examples in this guide with a pointer to a
download area for the source code.
Related Documents
Additional transition tools and documentation are available from the Tru64 UNIX
to HP-UX 11i Application Transition Web site:
http://www.hp.com/go/tru64appmigration
The HP Software Transition Kit is a must for anyone porting applications to
HP-UX 11i. It can be found on the Web at:
http://www.hp.com/go/STK
See the References section at the end of each chapter and Chapter 20 for a more
complete list of resources for Tru64 UNIX and HP-UX 11i.
xvi
About This Guide
Publication History
The guide’s publication date indicates its current edition. The publication date
changes when a new edition is released.
Tru64 UNIX to HP-UX 11i Porting Guide For PA-RISC and Itanium®-based
Systems
May 2005, Edition 5
•
Updated for the HP-UX 11i v2 September 2004 release, new clustering
roadmap, and compiler updates.
•
Change the Tru64 UNIX baseline used for comparison to Tru64 UNIX Version
5.1B.
October 2003, Edition 4
•
Added information on porting to HP-UX 11i v2.
•
Added information on the Tru64 UNIX to HP-UX application transition tools.
•
Change the Tru64 UNIX baseline used for comparison to Tru64 UNIX Version
5.1A.
January 2003, Edition 3
•
Added information on porting to HP-UX 11i v1.
•
Changed title to reflect content change.
Tru64 UNIX to HP-UX 11i on Itanium® Processors Porting Guide
August 2002, Edition 2
•
Update for HP-UX 11i v1.6.
June 2002, Edition 1
•
HP-UX 11i Version 1.5 release.
The document is available at:
http://www.hp.com/go/application-transition
Reader’s Comments
HP welcomes any comments and suggestions you have on this guide.
You can send comments to:
[email protected]
A Reader’s Comment form is located at the back of this guide.
Please include the following information along with your comments:
•
The full title of the manual.
•
The section numbers and page numbers of the information on which you are
commenting.
•
The versions of Tru64 UNIX and HP-UX that you are using.
We will not respond to system problems or technical support inquiries. Please
address technical questions to your local system vendor or to the appropriate HP
technical support office. Information provided with the software media explains
how to send problem reports to HP.
About This Guide
xvii
Conventions
This guide uses the following typographical conventions:
%
$
A percent sign represents the C shell system prompt. A
dollar sign represents the system prompt for the Bourne,
Korn, and POSIX shells.
% cat
Boldface type in interactive examples indicates typed
user input.
file
Italic (slanted) type indicates variable values, placeholders,
and function argument names.
..
.
A vertical ellipsis indicates that a portion of an example
that would normally be present is not shown.
...
cat(1)
In syntax definitions, a horizontal ellipsis indicates that
the preceding item can be repeated one or more times.
A cross-reference to a reference page includes the
appropriate section number in parentheses. For example,
cat(1) indicates that you can find information on the cat
command in Section 1 of the reference pages.
[|]
{|}
In syntax definitions, brackets indicate items that are
optional and braces indicate items that are required.
Vertical bars separating items inside brackets or braces
indicate that you choose one item from among those listed.
The following icons are used to denote platform-specific sections:
Denotes information specific to Itanium®-based development.
Denotes information specific to 64-bit Itanium®-based development.
Denotes information specific to 32-bit Itanium®-based development.
Denotes information specific to PA-RISC development.
xviii
About This Guide
Denotes information specific to 64-bit PA-RISC development.
Denotes information specific to 32-bit PA-RISC development.
In addition, the following conventions and terms are used:
•
Decimal constants consist of a sequence of decimal digits (0-9) without a
leading zero.
•
Hexadecimal constants consist of the characters 0x (or 0X) followed by a
sequence of hexadecimal digits (0-9abcdefABCDEF). Unless otherwise stated
these constants are represented in little-endian byte order.
•
Octal constants consist of a leading zero followed by a sequence of octal digits
(0-7). Unless otherwise stated these constants are represented in little-endian
byte order.
•
Binary constants consist of a sequence of binary digits (0-1) with a trailing b.
Unless otherwise stated these constants are represented in little-endian bit
order and little-endian byte order.
•
A byte is defined to be 8 bits.
About This Guide
xix
1
Porting Overview
_________________________
Note
_________________________
This guide provides information and hints on porting from Tru64
UNIX to HP-UX 11i. It is intended for developers who need to migrate
applications from Tru64 UNIX to HP-UX 11i and assumes that you have
software development experience on Tru64 UNIX.
The latest version of this guide is available from the Application
Transition Web site:
http://www.hp.com/go/application-transition
Additional transition tools are available from the Tru64 UNIX to HP-UX
11i application transition Web site:
http://www.hp.com/go/tru64appmigration
The primary focus of this guide is the migration of applications from
Tru64 UNIX Version 5.1B to HP-UX 11i v2. However, information is
provided on other release versions where differences exist. Throughout
this guide, whenever HP-UX 11i is referred to without any qualifying
version number it will refer to the current release on both PA-RISC
and Itanium®-based platforms.
We will continue to update this guide to reflect feedback from customers
and ISVs on their porting experiences, and as new tools become
available to further ease the porting process. Technical updates and
errata will be published in the companion document, Technical Update
for Tru64 UNIX to HP-UX 11i Porting Guide, available from:
http://www.hp.com/go/application-transition
Porting is the process of taking software that runs on one operating system
and computer architecture and making it run on another operating system or
architecture. In some cases, where the operating systems or architectures are
closely related, or when the source code of the software has particularly been
designed to be portable, the port really is straightforward: recompile the sources
and run the validation tests to verify that the new program operates just like
the original.
More often, there are difficulties in following this straightforward model. The
porting process then has a number of steps, which we will cover in this chapter.
The emergence and adoption of standards such as POSIX.1, UNIX 95, and UNIX
98 has led to a convergence in programming APIs. This has greatly reduced the
difficulty of porting but has not eliminated it. First, conformance to a standard is
an ongoing process of ever closer approximation. Once a high degree of conformance
is achieved, the remaining rare discrepancies are often found only after someone
doing a port stumbles on an area that may have been ambiguous in the standard or
was not exactly covered by a conformance suite, but was nevertheless implemented
in different ways on the two platforms. Second, some behaviors were left undefined
by the standards. Applications that rely on a particular vendor’s implementation
Porting Overview
1–1
of undefined behavior or on a particular vendor’s extensions to a standard will
require additional effort when porting.
1.1 Porting Process
The following outline lists the stages of a typical porting project:
1.
Identify the tools, products, and development environment your application
relies on.
2.
Assess the likely impact of how the various porting issues affect your
application.
3.
Clean up the code, identifying and removing architectural dependencies and
nonstandard practices if possible.
4.
Compile the code, preferably using ANSI error-checking switches to flag
potential issues. Fix any problems found at compile time.
5.
Run the application with a broad set of test cases, and debug and fix any
run-time problems that are detected.
6.
Recompile the code and repeat the process, as necessary.
1.2 Operating System Version Identification
The information in this guide is based on Tru64 UNIX Version 5.1B. Even if the
application you are porting is based on a different version of Tru64 UNIX, most of
the content of this guide still applies.
The information in this guide is also based on HP-UX 11i. Throughout this guide,
whenever HP-UX 11i is referred to without any qualifying version number it will
refer to all current releases on both PA-RISC and Itanium®-based platforms.
Version Aliases
Operating system versions have an official, external name and an internal name.
The official name is what appears on distribution media, manuals, and other
publications. The internal name is reported from software interfaces such as the
uname(2) system call or the uname(1) command.
Each HP-UX 11i release has an associated release name and identifier. The
uname(1) command with the -r option returns the release identifier. Table 1–1
shows the relationship between release identifier and name for HP-UX 11i.
Table 1–1: HP-UX 11i Release Names and Identifiers
Release
Identifier
Release Name
Supported Processor Architecture
B.11.11
HP-UX 11i v1
PA-RISC
B.11.20
HP-UX 11i v1.5a
Intel® Itanium® processor family
B.11.22
HP-UX 11i v1.6
Intel® Itanium® processor family
B.11.23
HP-UX 11i v2
PA-RISC and Intel® Itanium®
processor family
a No longer supported. Support information is available from:
http://www.hp.com/softwarereleases/releases-media2/history/slide2.html
Each release of Tru64 UNIX has an associated release name and identifier. The
uname(1) command with the -rv options returns the release identifier. The
release name is reported on the first line of the default /etc/motd file or by the
/usr/sbin/sizer -v command. Table 1–2 provides a mapping between release
identifiers and names.
1–2
Porting Overview
Table 1–2: Tru64 UNIX Release Names and Identifiers
Release
Identifier
Release Name
V4.0 1229
Digital UNIX Version 4.0Fa
V4.0 1530
4.0Ga
Digital UNIX Version
Supported Processor Architecture
Alpha processor
Alpha processor
Compaq Tru64 UNIX Version
5.0Aa
Alpha processor
V5.1 732
Compaq Tru64 UNIX Version
5.1a
Alpha processor
V5.1 1885
Compaq Tru64 UNIX Version 5.1Aa Alpha processor
V5.1 2650
Compaq Tru64 UNIX Version 5.1B Alpha processor
V5.0 1094
a Prior Version Support only. Support information is available from:
http://h30097.www3.hp.com/pdf/pvs_letter_0604.pdf
1.3 Porting and Coding Practices
Most of the coding practices in this guide are not specific to any one vendor, nor are
they specific to the Tru64 UNIX operating system. They are simply good, standard
coding practices. A number of books are available that cover similar ground. Some
of the better ones include:
•
The C Programming Language, Second Edition, by Brian W. Kernighan and
Dennis M. Ritchie; Prentice-Hall Software Series, Prentice-Hall, Inc.
•
C Traps and Pitfalls, by Andrew Koenig; Addison-Wesley Publishing Company
1.4 Porting Services
If you want assistance migrating your application to HP-UX 11i, HP has Partner
Technology Access Centers that offer application certification and porting services
to ISVs. For more information, visit the DSPP Web site at the following URL:
http://www.hp.com/dspp/
Porting Overview
1–3
2
Porting Effort and Considerations
This chapter provides information to help you assess the effort involved in porting
your application from Tru64 UNIX to HP-UX 11i.
2.1 Tru64 UNIX to HP-UX Application Transition Tools
HP has developed a set of tools and documentation to facilitate porting applications
from Tru64 UNIX to HP-UX 11i. These tools include:
•
binaryScan
•
Tru64 UNIX to HP-UX Software Transition Kit (STK)
•
Tru64 UNIX Migration Environment for HP-UX
The following sections describe these tools in more detail.
2.1.1 binaryScan
binaryScan is a planning tool that you can use to scope the porting effort.
It produces a listing of the Tru64 UNIX APIs used by a Tru64 UNIX shared
executable, along with an associated disposition code for each API. The
disposition code indicates whether any coding changes might be required
to utilize this API on HP-UX 11i (examples of disposition codes are fully
supported, code change possibly required, and code change required). A wizard
is also provided for customizing the binaryScan reports. You can download
the binaryScan tool from:
http://www.hp.com/go/tru64appmigration
2.1.2 Tru64 UNIX to HP-UX Software Transition Kit
The Tru64 UNIX to HP-UX Software Transition Kit (STK) includes the
following components:
•
File-scanning utilities
•
User documentation
The file-scanning utilities assist developers with the identification and
resolution of compatibility issues between Tru64 UNIX and HP-UX 11i on
Itanium®-based systems. These tools scan C, C++, and FORTRAN source
files, make files, and shell scripts, and produce text or HTML-based reports.
The file-scanning utilities include the scansummary tool, which can be used
to scope the migration effort, and the scandetail tool, which produces a
detailed report. The scansummary tool lists the number and types of API
impacts in the source files, while scandetail flags the exact API impacts
in the source files. For first time users of the file scanning utilities, HP
recommends using scanwizard, an interactive command-line wizard that
provides assistance with generating a custom detailed or summary report.
The user documentation includes the following documents (in PDF format):
Porting Effort and Considerations
2–1
•
Porting guide
–
•
Tru64 UNIX to HP-UX 11i Porting Guide
White papers
–
Common C Language Issues
–
Guide to Using HP WDB for Ladebug Users
–
Introduction to HP Caliper for DCPI Users
–
Migrating from Tru64 UNIX to HP-UX Shells
–
Migrating I18N and L10N Applications and Data from Tru64 UNIX
to HP-UX
–
Porting Compaq Fortran Applications on Tru64 UNIX to HP-UX
The Tru64 UNIX to HP-UX Software Transition Kit can be downloaded from:
http://www.hp.com/go/STK
2.1.3 Tru64 UNIX Migration Environment for HP-UX
The Tru64 UNIX Migration Environment for HP-UX (Migration Environment) is
a run-time environment on HP-UX 11i that includes selected Tru64 UNIX APIs,
development tools, commands, and utilities. It will help you rapidly migrate your
Tru64 UNIX applications to HP-UX 11i on PA-RISC and Itanium®-based systems.
You can use the Migration Environment as an intermediate step on the path to
developing native HP-UX 11i applications.
The Migration Environment includes selected development tools, such as the Tru64
UNIX make command and compiler (cc) and linker (ld) jackets, which map Tru64
UNIX command-line options to the equivalent HP-UX 11i options (if there is a
match). The utilities and commands included in the Migration Environment are:
cc
ld
make
man
stty
mcs
mkcatdefs
tar
dspcat
cpio
dspmsg
pax
The Migration Environment includes libraries and associated header files
containing Tru64 UNIX based APIs to assist developers porting applications
to HP-UX 11i. It includes both a shared library, libtru64.so, as well a
static library, libtru64_ext.a. In version 1.3 (and earlier versions) of the
Migration Environment, the shared library, libtru64.so, contained APIs under
consideration for native implementation in future releases of HP-UX 11i. Many of
these APIs have been implemented in the base operating system as of the HP-UX
11i v2 May 2005 release.
Starting with version 1.4 of the Migration Environment, libtru64.so has been
replaced with a symbolic link to the base operating system library, libcext.so,
which contains many of the APIs formerly in libtru64.so. The remainder of
the libtru64.so APIs have been moved to the Migration Environment static
library, libtru64_ext.a. Interfaces in libtru64_ext.a are not expected to be
implemented as native APIs in HP-UX 11i, but are available as an intermediate
porting aid for developers who are on the path to developing fully native HP-UX
11i applications.
Note that existing applications with dependencies on any libtru64.so APIs
that have been moved to libtru64_ext.a as of version 1.4 of the Migration
2–2
Porting Effort and Considerations
Environment will need to relink their applications once they have installed version
1.4 of the Migration Environment on HP-UX 11i v2 May 2005 or later releases.
Refer to the Migration Environment documentation before installing version 1.4
for details about API dependencies and options.
Also, refer to the documentation provided with the Portability Package included
in the HP-UX 11i v2 May 2005 release for details on using the portability library
and headers, which contain the previously mentioned Migration Environment
functionality as part of the base HP-UX 11i operating system.
The Tru64 UNIX Migration Environment for HP-UX can be downloaded from:
http://www.hp.com/go/tru64appmigration
2.2 Third-Party Software and Tools
The availability of third-party software is often the biggest obstacle when planning
a porting project. You must determine the availability and cost of third-party
software for the target operating system. This may include build environment
tools, third-party libraries, and automated testing tools. See Chapter 19 for
information about tools that are freely available on HP-UX 11i.
2.3 Scripts
All common commands and utilities specified in the POSIX standard are supported
by both platforms. Primary differences usually involve options that are supported
on one platform but not on the other, or the location of files. For example, the
POSIX shell on Tru64 UNIX is located in /usr/bin/posix/sh. On HP-UX 11i
the POSIX shell is in /usr/bin/sh.
The Tru64 UNIX to HP-UX Software Transition Kit includes a document
called Migrating from Tru64 UNIX to HP-UX Shells, which highlights the
differences between the two platforms. This document is also available from:
http://devrsrc1.external.hp.com/STKT/portguides.html
2.4 Build Environment
Tru64 UNIX provides three versions of the make command; HP-UX 11i has one
version. The HP-UX 11i implementation of make is XPG4/POSIX compliant.
Tru64 UNIX developers who are not using the XPG4/POSIX compliant version
(found in /usr/bin/posix/make) may need to modify their build environment
on HP-UX 11i. See Chapter 6 for information on the differences in make on the
two operating systems.
You can also use the Tru64 UNIX Migration Environment for HP-UX, which
provides the Tru64 UNIX default make command. It also includes cc and ld
drivers, which you can use to help port your makefiles to HP-UX 11i.
In environments where GNU make is currently in use, continue to use it for a
smooth migration to HP-UX 11i. See Chapter 19 for information on where to
obtain GNU make for HP-UX 11i.
When setting up your build environment, you should also consider any kernel
tuning parameters that need to be set to allow your application to build and run
successfully and with optimal performance. For a mapping from Tru64 UNIX to
HP-UX 11i of some commonly used tuning parameters, see Appendix F.
Porting Effort and Considerations
2–3
2.5 Compiling the Software
The following sections discuss language and programming issues you may
encounter when compiling your software.
2.5.1 Languages
Both Tru64 UNIX and HP-UX 11i C compilers support ANSI C (ANSI/ISO
9899-1990).
The cross-platform compatibility of your C source code can be assessed by choosing
one of the following strategies:
•
When porting to Itanium®-based systems, use the file-scanning utilities in
the Tru64 UNIX to HP-UX Software Transition Kit to assess the portability
of your code.
•
On Tru64 UNIX, try compiling with -std1, the strictest setting available, to
see how many potential problems exist with converting to strict ANSI C.
•
On HP-UX 11i, try using the -Ae option (ANSI C mode with extensions) with
the C compiler, if your code cannot be compiled in strict ANSI C mode.
A similar approach can be taken for C++ applications. The Tru64 UNIX and
HP-UX 11i C++ compilers are both based on the ANSI/ISO C++ International
Standard. Try the following strategies to assess the portability of your code:
•
When porting to Itanium®-based systems, use the file-scanning utilities in
the Tru64 UNIX to HP-UX Software Transition Kit to assess the portability
of your code.
•
On Tru64 UNIX, try compiling with -std strict_ansi to see how many
potential problems exist with converting to strict ANSI C++.
•
If you are not using the standard iostream classes on Tru64 UNIX, then on
HP-UX 11i you will need to use the -AP switch with the HP aC++ compiler to
continue using the older libraries and header files. This is the default setting
for the compiler on HP-UX 11i v1, but not for HP-UX 11i v2. See Section 4.2.1
for more information.
The GNU Compiler Collection (gcc) is available for Tru64 UNIX and HP-UX
11i. If your application is currently using gcc on Tru64 UNIX, continued use
on HP-UX 11i will make your migration easier. However, performance-sensitive
applications should give serious consideration to using the native HP compilers as
the resulting executables will most likely have significantly better performance
than the same application built with the GNU Compiler Collection. See Chapter 19
for information on where to obtain GNU tools for HP-UX 11i.
2.5.2 Porting Pitfalls
The following practices may require additional modifications to your code in order
to successfully port to another platform:
2–4
•
Using undocumented interfaces
•
Relying on behaviors that are undefined in the language and operating system
standards
•
Using kernel-intrusive functions
•
Using assembler or inline assembler directives
•
Taking advantage of compiler-specific enhancements, rather than coding to
the ANSI standard
Porting Effort and Considerations
When porting to Itanium®-based systems, use the file-scanning utilities in the
Tru64 UNIX to HP-UX Software Transition Kit to help determine whether
your application exhibits any of these types of problems.
2.5.3 Developing 64-Bit Applications
For Tru64 UNIX, 64-bit applications are the default. HP-UX 11i creates 32-bit
executables and/or shared libraries by default. To create a 64-bit program, all files,
including third-party libraries, must be compiled and linked using the +DD64
option.
Both platforms use the LP64 standard, which means that both long integers and
pointers are 64-bit values. However, the virtual memory layouts are different as
are several of the run-time behaviors. For details on the virtual address layouts,
see Section 5.2.2.
2.5.4 Developing 32-Bit Applications
Both Tru64 UNIX and HP-UX 11i support 32-bit images. Under Tru64 UNIX, these
applications are known as Truncated Address Space Objects (TASO) programs, and
they require special compiler and linker switches. These images are IP32, not
ILP32; under Tru64 UNIX long elements are always 64-bit data types.
HP-UX 11i creates 32-bit, ILP32, images by default; in these images long elements
are a 32-bit data type. As a result, these images do not provide a direct mapping
for TASO applications. Programs requiring 64-bit integer math should use
int64_t/uint64_t element types as defined by the C standard. The address space
layout and some of the run-time behaviors are also different than on Tru64 UNIX
and need to be considered. For virtual address layout details, see Section 5.2.2.
The linker and run-time loader environments are significantly different between
the two platforms. For details on these differences, see Chapter 5.
2.5.5 The 32-Bit Versus 64-Bit Choice
On Tru64 UNIX, all applications, whether compiled as 64-bit applications or with
the -xtaso and/or -taso build options, use the same set of system libraries that
support applications compiled with 64-bit address pointers and data structures.
On HP-UX 11i, you have a choice of whether to build an application as a 64-bit
application or a traditional 32-bit application and a corresponding choice of system
libraries. The following table lists some hints to help you decide whether to build
your application on HP-UX 11i as a 64-bit application or not:
Porting Effort and Considerations
2–5
Build as 64-bit if....
Build as 32-bit if...
•
Your application has requirements for
large memory address spaces. That is,
the application supports large amounts
of data, greater than 1.75 GB, allocated
in memory, or the application will map
large files into its address space.
•
You use the -xtaso or -taso build
options currently on Tru64 UNIX. This
probably means your application is not
64-bit clean. In this case, the easiest
thing to do is to just compile it as a 32-bit
application.
•
You use third-party libraries in your
application that are only available in
64-bit versions.
•
You know you will never need to
map large files into the program
address space, or allocate more than
approximately 1.75 GB of data segment
space for your application.
•
You use third-party libraries in your
application that are only available in
32-bit versions.
2.6 Testing and Test Scripts
The time and expense required to port or acquire testing tools must be factored
into the porting assessment. If you have developed automated test tools, then
these tools will need to be ported to HP-UX 11i. If you are using testing tools
provided by a third party, then you will need to check on the availability of these
tools on HP-UX 11i.
2.7 Debugging
Developers who are accustomed to using ladebug or dbx on Tru64 UNIX will
generally need to learn the WDB debugger provided with HP-UX 11i. See the
WDB for Ladebug Users guide supplied with the Tru64 UNIX to HP-UX Software
Transition Kit. WDB is based upon gdb, so there will be less of a learning curve for
users who are familiar with gdb. For more information on WDB, see Section 6.2.
2.8 Optimization
Optimization is an important step in the porting process, and will allow you to take
full advantage of your HP-UX 11i platform. Optimization may include using the
appropriate compiler options (see Chapter 4) or using performance analysis tools
such as HP Caliper (see Section 6.3). Allocate time to learn any new tools that are
required for the optimization process.
2.9 Packaging and Distribution
If you have a software package that is distributed to multiple sites, you may
want to package it in HP-UX Software Distributor (SD) format, which allows
you to manage the software with the SD software management toolset. For
more information on packaging in SD format, see Chapter 10 (Creating Software
Packages) in the Software Distributor Administration Guide for HP-UX 11i or by
accessing the swpackage(1M) reference page. These documents and additional
information can be found at:
http://www.docs.hp.com/en/SD/
In addition, the Software Depot Cookbook can be found at:
http://software.hp.com/SD_AT_HP/docs/cookbook.html
A new application called Software Package Builder (SPB) is available to help
you create a Product Specification File (PSF) that is required for packaging in
SD format. HP delivers SPB as a customer selectable software for all operating
2–6
Porting Effort and Considerations
environments beginning with the HP-UX 11i v2 release and the HP-UX 11i v1
September 2003 release. Additional information on SPB can be found at:
http://www.docs.hp.com/en/SPB/
The RPM format is another package format you may wish to consider. RPM is
not supported on either Tru64 UNIX or HP-UX 11i, but it is available for both.
While RPM is provided with the Tru64 UNIX operating system on the Open Source
Software Collection CD, it is not included with HP-UX 11i. For more information
on RPM, go to:
http://www.rpm.org/
2.10 References
Appendix G provides a porting checklist.
For the Tru64 UNIX to HP-UX Software Transition Kit, see:
http://www.hp.com/go/STK
For the Tru64 UNIX Migration Environment for HP-UX, see:
http://www.hp.com/go/tru64appmigration
Porting Effort and Considerations
2–7
3
HP-UX 11i Development Environment
This chapter provides an overview of the development environment for HP-UX 11i.
3.1 Standards Comparisons
HP-UX 11i conforms to many common industry standards. Table 3–1 provides a
comparison of standards conformance between Tru64 UNIX and HP-UX 11i.
Table 3–1: Tru64 UNIX and HP-UX 11i Standards Comparison
Standard
Tru64 UNIX
HP-UX 11i
Single UNIX Specification, Version 1 (UNIX 95)
Yes
Yes
Single UNIX Specification, Version 2 (UNIX 98)
Yes
Noa
IEEE POSIX 1003.1c Kernel threads
Yes
Yes
IEEE POSIX 1003.1c System APIs
Yes
Yes
IEEE POSIX 1003.1b Real-time scheduler, clocks and
timers, synchronous I/O, semaphores APIs
Yes
Yes
IEEE POSIX 1003.4a Draft 4 User Threads
Deprecated
Deprecated
IEEE POSIX 1003.1b Asynchronous I/O, Memory
Locking, Message Queues, Real-Time Signals, Shared
Memory
Yes
Yes
IEEE POSIX 1003.2 (Commands and Utilities)
Yes
Yes
X/Open Portability Guide (XPG4)
Yes
Yes
ONC, NFS Version 2 and 3
Yes
Yes
System V Interface Definition (SVID3)
Yes
Yes
System V.4 (SVR4) File System Directory Layout
Yes
Yes
X11 Window System, Font Server and Clients
R6.5
R6.2
OSF/Motif
V1.2b
V2.1
OSF/Motif Application Environment Specification
(AES)
Yes
Yes
Federal Information Processing Standard (FIPS) 151-2
Yes
Yes
Federal Information Processing Standard (FIPS) 189
Yes
Yes
LP64, 64-bit data model
Yes
Yes
ILP32, 32-bit data model
No
Yes
IP32, 32-bit data model
Yes
No
a See http://www.hp.com/go/tru64appmigration for information on UNIX 98 branding (look for the “Working to
a standard” header under the technical resources tab)
b V2.1 is available on the Associated Products CD
3.2 System V Habitat
The System V Environment for Tru64 UNIX provides a UNIX System V Release 4
(SVR4) user environment for general users, application programmers, and system
administrators, by providing SVR4 commands, libraries, and tools as an extension
to the Tru64 UNIX operating system.
HP-UX 11i Development Environment
3–1
HP-UX 11i is the HP implementation of the UNIX System V, Release 4 operating
system. HP-UX 11i is compatible with industry standards and includes features
from the Fourth Berkeley Software Distribution. HP-UX 11i is the closest to a
stock System V UNIX of any of the modern UNIX operating system releases.
Because the System V environments on both Tru64 UNIX and HP-UX 11i comply
with industry standards, use of the Tru64 UNIX System V habitat should pose no
difficulty in migrating to the System V environment on HP-UX 11i.
3.3 Compiler Overview
This section provides an overview of the compilers supported on HP-UX 11i:
•
HP C
•
HP ANSI C
•
HP aC++
•
Java
•
HP Fortran
•
COBOL
Table 3–2 provides an overview of the HP-UX 11i compilers.
Table 3–2: HP-UX 11i Compilers
Compiler
Path
Notes
HP ANSI C
/opt/ansic/bin/cc
The HP ANSI C compiler plus
extensions for Itanium®-basedplatforms. No K&R support.
HP C
/opt/ansic/bin/cc
The ANSI C compiler for PA-RISC
platforms. HP C includes K&R
support.
c89
/opt/ansic/bin/c89
The C89 compiler. c89 is
equivalent to invoking cc with the
-Aa option.
HP C (Bundled)
/usr/ccs/bin/cc
The HP C bundled compiler for
PA-RISC platforms.
HP aC++
/opt/aCC/bin/aCC
ISO/IEC 14882 Standard for the
C++ Programming Language (the
international standard for C++).
HP Fortran
/opt/fortran90/bin/f90
Fortran 90 and Fortran 95
compliant compiler.
To verify the product number and version for your compiler, use the
/usr/bin/what (or cc -V) command. For example:
% what /opt/aCC/bin/aCC
/opt/aCC/bin/aCC:
HP aC++/C for Itanium®-based systems B3910B
A.05.55 [December 04 2003]
3.3.1 Compiler Licensing
The HP compilers must be purchased seperately; no compiler is included with the
base operating system. Licensing is enforced at install time through codeword
protection. Licensing software (for example, a license server) is not used.
3–2
HP-UX 11i Development Environment
3.3.2 HP aC++ and HP ANSI C Compilers
The HP ANSI C (B3901BA) and HP aC++ (B3913DB) compilers on HP-UX 11i are
licensed products that you need to purchase separately. Both compilers generate
high performance code for HP-UX 11i on Itanium®-based systems. These compilers
provide a smooth transition from PA-RISC systems, providing compatibility
features, options, and extensions to ease multi-platform development and other
transitions from platforms like Tru64 UNIX.
The HP aC++ compiler for Itanium®-based systems supports the ISO/IEC 14882
Standard for the C++ Programming Language (the international standard for C++).
The HP ANSI C compiler supports the ANSI Programming Language C standard,
ISO/IEC 9899:1990 (the C89 standard). The C compiler also provides partial C99
compliance. The K&R compilation mode is no longer available.
HP ANSI C and HP aC++ Version A.06.00 introduced several new features
including:
•
Stronger adherence to the latest ISO C++ and ISO C99 language standards,
including significantly improved support for C++ templates.
•
More helpful warning diagnostics for both C and C++.
•
Look-and-feel convergence with the Tru64 UNIX C and C++ compilers to
facilitate the migration of Tru64 UNIX applications to HP-UX.
Beginning with HP ANSI C Version A.05.36 for HP-UX 11i v1.6 on Itanium®-based
systems, the HP ANSI C compiler introduced changes that provide improved
similarity of functionality relative to the HP aC++ compiler while maintaining a
very high level of compatibility with the previous releases of the HP C compiler.
For example, this version of HP ANSI C now supports pre-compiled headers,
a feature that has been available for sometime in HP aC++. The C and C++
compilers also now generate the same warnings and error messages in comparable
circumstances. The goal of the changes was to simplify and ease the development
of code using a mixture of C and C++.
This updated version of the HP ANSI C compiler has very few incompatibilities
with its previously released version. These incompatibilities have minimal or no
impact on the applications that are migrated to Itanium®-based platforms.
For more information on HP ANSI C and HP aC++, go to:
http://www.hp.com/go/c
http://www.hp.com/go/c++
3.3.3 HP C/ANSI C Developer’s Bundle
The C compiler on PA-RISC systems is a separate product from the C++ compiler.
The compiler supports both ANSI C (C89) and K&R dialects as well as partial C99
compliance. Detailed documentation on the compiler is available at:
http://docs.hp.com/en/dev.html#C
For information on the HP C/ANSI C developer’s bundle, go to:
http://www.hp.com/go/ansic
3.3.4 Java 2 Platform
The Java™ 2 Standard Edition (J2SE™) products for HP-UX 11i provide solutions
to develop and deploy Java applications with the best performance on HP
servers and workstations. As a Java licensee, the HP releases of updated SDKs
closely follow the releases of new versions of the SDK by Sun Microsystems. The
HP-UX 11i Development Environment
3–3
latest Java 2 release for HP-UX 11i at the time of this writing is SDK Version
1.4.2.07, which supports the HotSpot virtual machine and includes the Run Time
Environment (RTE).
The default VM for Java on the HP platforms is 32-bit. You can enable the 64-bit
Hotspot VM by use of the flag -d64 on the command line. This option is not
available on Java versions prior to 1.4.1. On Tru64 UNIX, Java only runs in
64-bit mode.
For up-to-date information on the latest Java SDK and RTE releases as well as
Java development tools, browser plug-ins, and enhancements on HP platforms, see:
http://www.hp.com/go/java
3.3.5 FORTRAN
The FORTRAN compiler for HP-UX 11i is HP Fortran, which conforms to the
Fortran 95 (ISO/IEC 1539-1997) language standard. It leverages the Edinburgh
Portable Compiler (EPC) f90 frontend and supports the full OpenMP V2.0
language standard.
The HP Fortran compiler provides a common source base for all HP-UX 11i
operating systems and supports user directives to guide explicit data prefetching,
compile-time inlining, and common math library functions. The compiler is
complemented by the high-performance math run-time library and a linear algebra
package (assembly coded). It is validated against all major Mechanical Computer
Aided Engineering (MCAE) applications.
To display the product number and the release version of your HP Fortran compiler,
use the what command:
% what /opt/fortran90/bin/f90
/opt/fortran90/bin/f90:
HP-UX f90 B3907DB/B3909DB B.11.11.90/B.11.23.20
(PA RISC) Thu Sep 2 02:33:33 CDT 2004
HP F90 v2.9
Release notes for HP Fortran are available on the Web site:
http://docs.hp.com/en/dev.html#Fortran
They are also available in the /opt/fortran90/newconfig/RelNotes/
directory.
For information on HP Fortran for HP-UX 11i, see:
http://www.hp.com/go/fortran
3.3.6 COBOL
Micro Focus provides a native COBOL compiler, Micro Focus Server Express, for
HP-UX 11i. Existing applications compiled with Server Express for any Unix
platform can be made available on HP-UX without source code modification. For
product information, see:
http://www.microfocus.com/
Acucorp, Inc., an international provider of legacy extension solutions for COBOL
applications, provides support for Tru64 UNIX and HP-UX 11i with their extend®
product suite. The object files produced by ACUCOBOL-GT are 100 percent
portable across all platforms.
For more information on the Acucorp COBOL product offferings, see:
http://www.acucorp.com/
3–4
HP-UX 11i Development Environment
For more information on COBOL for HP releases, see:
http://www.hp.com/go/cobol
3.4 Location of Files and Utilities
On HP-UX 11i, the /usr/include/ and /opt/aCC/include*/ paths contain the
primary header file trees. These paths are searched by default by the C and C++
compilers. Table 3–3 lists the header file paths and their descriptions.
Table 3–3: Header File Paths
Path
Description
/usr/include/
The system’s general-use C and C++ include files
/usr/include/X11R6/
X11 Release 6
/usr/include/Motif2.1/
Motif Version 2.1
/opt/aCC/include*/
HP aC++ include files (automatically searched by
HP aC++)
/opt/ansic/include*/
The ANSI C include files for PA-RISC only
3.4.1 System Libraries
The system libraries are primarily kept in the /usr/lib/ tree. The default paths
searched by the linker are described in Section 5.1.5. Shared libraries are versioned
using System V standards and have a numerical suffix; internal version strings are
not used. A different default suffix is used to distinguish between PA-RISC and
Itanium® shared libraries. Itanium® shared libaries use a suffix of .so; PA-RISC
shared libaries use .sl. The default suffixed library is typically a link to the most
recent version of the library.
_________________________
Note
_________________________
Archive (.a) files for system libraries are not provided for HP-UX 11i on
Itanium®-based systems, and archive libraries have been deprecated
in HP-UX 11ifor PA-RISC systems. See Chapter 13 for a detailed
comparison of libraries between Tru64 UNIX and HP-UX 11i.
To support four run-time environments, HP-UX 11i provides four sets of libraries.
Not all libraries are available for each environment. Itanium®-based systems can
run PA-RISC images in emulation mode, so the PA-RISC libraries are provided on
this platform in addition to the Itanium® libraries. Itanium® images cannot be run
on PA-RISC systems, so only the PA-RISC libraries are available on this platform.
Table 3–4, Table 3–5, Table 3–6, and Table 3–7 list the library paths and their
descriptions. For additional information on graphics libraries, see Chapter 14.
Table 3–4: 64-Bit Itanium® Library Paths
Path
Description
/usr/lib/hpux64/
System libraries
/usr/lib/hpux64/X11R6/
Current X11 Release 6 libraries
/usr/lib/hpux64/Motif2.1/
X11 Motif libraries
/opt/langtools/hpux64/lib/
Language tools libraries
HP-UX 11i Development Environment
3–5
Table 3–5: 32-Bit Itanium® Library Paths
Path
Description
/usr/lib/hpux32/
System libraries
/usr/lib/hpux32/X11R6/
Current X11 Release 6 libraries
/usr/lib/hpux32/Motif2.1/
X11 Motif libraries
/opt/langtools/hpux32/lib/
Language tools libraries
Table 3–6: 64-Bit PA-RISC Library Paths
Path
Description
/usr/lib/pa20_64/
System libraries
/usr/lib/X11R6/pa20_64/
Current X11 Release 6 libraries
/usr/lib/Motif2.1/pa20_64/
X11 Motif libraries
/opt/langtools/lib/pa20_64/
Language tools libraries
/usr/ccs/lib/pa20_64/
Compiler libraries
Table 3–7: 32-Bit PA-RISC Library Paths
Path
Description
/usr/lib/
System libraries
/usr/lib/X11R6/
Current X11 Release 6 libraries
/usr/lib/X11R5/
X11 Release 5 libraries
/usr/lib/Motif2.1/
X11 Motif libraries
/usr/lib/Motif1.2/
Motif Version 1.2 libraries
/usr/lib/Motif1.1/
Motif Version 1.1 libraries
/usr/dt/lib/
Desktop, Tooltalk, and CSA libraries
/opt/langtools/lib/
Language tools libraries
/usr/ccs/lib/
Compiler libraries
3.5 Patches for HP-UX 11i
You may obtain HP-UX 11i patches in several different ways:
•
The Extension SoftWare (XSW) CD-ROMs. These CD-ROMs are distributed
regularly. They contain bundles for each of the hardware operating system
releases currently supported. The bundles are updated at regular intervals to
keep pace with the current patches available. When such an update happens,
all the patches in the bundle undergo extensive coexistence testing.
•
The HP Enterprise Response Centers provide HP-UX 11i patches that are
tailored by engineers assisting you in solving problems. You must have a
support agreement with HP to use the Response Centers.
•
Research and download patches, according to your own personal patch
management strategy, by using HP’s Patch Management tools available from
the IT Resource Center (ITRC):
http://itrc.hp.com
Choose proven patches for stability, new patches for cutting-edge functionality,
or HP’s highest rated patches.
When installing software on your HP-UX 11i system, be sure to read the release
notes for each software component you install, and verify that the recommended
3–6
HP-UX 11i Development Environment
and required patches are installed. Software packages currently installed on a
system can be listed using /usr/sbin/swlist. Check the patch-related reference
pages for more information: swlist(1M), swinstall(1M), and swremove(1M).
3.6 References
HP Developer and Solution Partners Portal
http://www.hp.com/dspp/
The HP IT Resource Center
http://itrc.hp.com/
HP-UX 11i Development Environment
3–7
4
Compilers
This chapter covers porting considerations for the primary compilers available
for Tru64 UNIX and HP-UX 11i. This includes C, C++, Java, FORTRAN, and
assembler. Note that the HP-UX 11i compilers all generate 32-bit objects by default
and it is necessary to use the compiler option +DD64 to build a 64-bit program.
4.1 C Compilers
The information in this section is based on HP C Version B.11.23.02 for HP-UX
11i v2 on PA-RISC platforms and HP ANSI C Version A.06.01 for HP-UX 11i
v2 on Itanium®-based platforms. The Tru64 UNIX and HP-UX 11i C compilers
all support ANSI C (ANSI/ISO 9899-1990). They also all provide partial C99
(ANSI/ISO 9899:1999) compliance (see the compiler release notes for details
about which features each compiler supports). Code should be written in strict
conformance with ANSI C whenever possible to provide the greatest level of
portability and the most consistent behavior across all platforms. The following
sections discuss these compilers in more detail.
4.1.1 Language Differences
The HP-UX 11i C compilers, in their default mode (-Ae), support ANSI C with
some extensions. The Compaq C compiler, in its default mode (-std), supports the
relaxed ANSI C language mode. This relaxed mode enforces the ANSI C standard,
but allows some common programming practices not allowed by the standard.
If you are using the -std or -std0 options with Compaq C, then the degree of
compliance in your code with the ANSI standard may vary. To check for potential
problems, compile your code with the Compaq C -std1 option, which enforces
strict ANSI C mode. In addition, it may be useful to define -D_XOPEN_SOURCE for
Compaq C compilations. This will cause _OSF_SOURCE to not be defined, and
flag the use of any Tru64 UNIX specific data structures in your source code. Any
references to these data structures will indicate code that needs to be modified
as part of your porting effort.
4.1.2 Language Mode Options
Table 4–1 provides a mapping from the commonly used Compaq C language mode
options to the equivalent options for HP C and HP ANSI C. It also shows which
options are the default on each platform. Note that there are differences in the
namespaces that are defined by default on the two operating systems. Specifically,
with the -Aa option on HP-UX 11i, the ANSI C namespace is the default. The
namespace may need to be relaxed to allow programs to compile in ANSI mode.
See Section 4.7 for more information on namespaces for the two platforms.
Table 4–1: C Language Mode Options
Compaq C
HP C and HP ANSI C
Description
-std (Version 5.x default)
-Ae (default)
ANSI C mode with extensions
-std0 (Version 4.0x default)
-Ac (HP C on PA-RISC only) K&R C
-std1
-Aa
Strict ANSI C
-c99
-AC99
ANSI C99
Compilers
4–1
4.1.3 C Compiler Options
___________________
Common Mistake
___________________
The HP C and HP ANSI C default is to produce 32-bit objects. To
compile in 64-bit mode, use the +DD64 command-line option.
_____________________
Best Practice
_____________________
By default, the Compaq C compiler generates instructions that are appropriate
for all Alpha processors (-arch generic). On PA-RISC platforms, the
default is to generate instructions for the architecture of the system where the
compilation is performed. If your application will need to run on both PA-RISC
1.1 and 2.0 platforms, then compile with the +DAportable option.
The C compilers on both operating systems allow the passing of command-line
options through environment variables. The Compaq C compiler reads the DEC_CC
environment variable for additional command-line options. The equivalent
environment variable for the HP C and HP ANSI C compiler is CCOPTS.
See Appendix A for a complete list comparing the Compaq C options to the HP C
and HP ANSI C options.
_____________________
Best Practice
_____________________
You can use the cc driver included in the Tru64 UNIX Migration
Environment for HP-UX to map your Compaq C compiler options to the
equivalent options for HP ANSI C. Use the -port_info_only option
with the cc driver to display the HP ANSI C options that map to the
Compaq C options specified on the command line. Example 4–1 and
Example 4–2 show examples of the output from the cc driver when the
-port_info_only option is used. In this case, no compiler options are
included on the command line so you can see what options are being
set by default.
Example 4–1: Using the Migration Environment cc Driver with -port_info_only
on PA-RISC Platform
% /opt/tru64/bin/cc -port_info_only -c foo.c
/opt/tru64/bin/cc: Tru64 UNIX Migration CC Driver V1.3
/opt/tru64/bin/cc:
/opt/ansic/bin/cc +FPOZ +O1 +Olit=none -Ae -I/opt/tru64/include
-c foo.c +DD64
Example 4–2: Using the Migration Environment cc Driver with -port_info_only
on Itanium®-based Platform
% /opt/tru64/bin/cc -port_info_only -c foo.c
/opt/tru64/bin/cc: Tru64 UNIX Migration CC Driver V1.3
/opt/tru64/bin/cc:
/opt/ansic/bin/cc +FPOZ -O1 +Olit=none -Ae -I/opt/tru64/include -c
foo.c -Bextern -fpeval=float +Olibmerrno +DD64 -dynamic
4–2
Compilers
4.1.4 Preprocessor Macros
Table 4–2 lists the preprocessor macros that are defined by the C compilers.
Compaq C defines __unix__; the HP-UX 11i C compilers define __unix. The
_ILP32 macro is the default on HP-UX 11i; using the +DD64 option will cause
__LP64__ and _LP64 to be defined instead.
Table 4–2: C Preprocessor Macros
Compaq C
HP C (PA-RISC)
HP ANSI C (Itanium®
Processor Family)
__alpha
__hppa
__ia64
__arch64__
_ILP32 or _LP64
_ILP32 or _LP64
__digital__
Not Available
Not Available
__osf__
__hpux
__hpux
__unix__
__unix
__unix
__DECC_VER=<version>
__HP_cc=<version>
__HP_cc=<version>
__LANGUAGE_C__
Not Available
Not Available
_LONGLONG
Not Available
_INCLUDE_LONGLONG
_SYSTYPE_BSD
Not Available
Not Available
Not Available
Not Available
_BIG_ENDIAN
4.1.5 Optimization
Table 4–3 compares the compiler optimization levels available with Compaq C and
the HP-UX 11i C compilers. Both platforms have five levels of optimization through
the -On option, where n is 0-4, and each level is a superset of all lower levels.
With no optimization specified, the default for Compaq C is -O1; the default
for the PA-RISC C compiler is -O0.
The default on the Itanium® processor family is -O1. Also, the effect of the
-O4 option is significantly different between the two platforms. For HP ANSI
C on the Itanium® processor family, -O4 performs full optimizations across
the entire application.
The compilers on both operating systems also provide a -fast option, which sets
a combination of switches for optimizing execution time. Table 4–3 lists these
settings. For information on the individual options, see Appendix A or the compiler
reference pages.
In addition, the HP ANSI C compiler for the Itanium® processor family has a
+Ofaster option, which selects -fast but sets the optimization level to -O4.
Compilers
4–3
Table 4–3: C Compiler Optimization Levels and Descriptions
Optimization
Level
Compaq C
HP C and HP ANSI C
-O0
None
(Default for PA-RISC) Constant
folding and simple register
assignment.
-O1
(Default) Local optimizations and
recognition of common subexpressions.
Global optimizations, including code motion,
strength reduction and test replacement,
split lifetime analysis, and code scheduling.
(Default for Itanium® processor
family) Instruction scheduling and
optimizations that can be performed
on small sections of code.
-O2 or -O
Inline expansion of static procedures.
Additional global optimizations that
improve speed (at the cost of extra code size),
such as integer multiplication and division
expansion (using shifts), loop unrolling, and
code replication to eliminate branches.
Optimizations performed over
entire functions in a single file.
Optimizes loops to reduce pipeline
stalls. Performs scalar replacement
and analysis of data flow, memory
usage, loops, and expressions.
-O3
Inline expansion of global procedures.
Full optimization across all
subprograms within a single file.
Includes subprogram inlining.
-O4
Software pipelining using dependency
analysis, vectorization of some loops on
8-bit and 16-bit data (char and short),
and insertion of NOP instructions to improve
scheduling.
Full optimizations across the
entire application program.
Includes global and static variable
optimization and inlining across the
entire program. Optimizations are
performed at link time.
-fast
-ansi_alias
-ansi_args
-assume nomath_errno
-assume trusted_short_alignment
-D_INTRINSICS
-D_INLINE_INTRINSICS
-D_FASTMATH -float
-fp_reorder
-ifo
-intrinsics
-O3
-readonly_strings
For PA-RISC:
+O3
+Onolooptransform
+Olibcalls
+FPD
+Oentryschedule
+Ofastaccess
For Itanium® processor family:
+O2
+Onolimit
+Ofltacc=relaxed
+FPD
+DSnative
+Oshortdata
+Ofaster
Not Available
(Itanium® processor family
only) Selects -fast but with
optimization level increased to .+O4.
4.1.6 Known Issues with Porting K&R C Code
The following sections discuss some known porting issues involving K&R C source
code.
4.1.6.1 Calling Functions without Prototypes
______________________
Workaround
______________________
The problem described in this section can be avoided by using the HP ANSI
C option +tru64 on the command line. Specifying +tru64 will cause the
HP ANSI C compiler to behave similarly to the Compaq C compiler for the
example in this section. The recommended solution is to make sure that your
application source code contains prototypes.
4–4
Compilers
A known difference in the C compilers exists when calling functions without
prototypes. C functions that are not explicitly declared are assumed to be of type
int. Tru64 UNIX was developed as a 64-bit operating system, with an LP64 data
model, and treating undeclared functions as if they were int was a large barrier to
porting applications from ILP32 platforms. The biggest instance of this problem
was in calling malloc( ) without declaring it. To take full advantage of the 64-bit
processor, the Tru64 UNIX compilers always use 64-bit values when returning
values from functions. Any conversion of return values to smaller types is expected
to be performed explicitly in the calling routine.
The HP-UX 11i compilers clean the upper 32 bits of the value returned from
implicitly declared functions. This may cause applications that do not declare
functions to obtain different results on HP-UX 11i than on Tru64 UNIX.
Example 4–3 shows a simple program that demonstrates this problem. On
Itanium®-based systems, you can use the +tru64 compiler option to obtain
behavior similar to the Compaq C compiler. The recommended solution is to make
sure that your application source code contains prototypes.
Example 4–3: Calling Functions without Prototypes on HP-UX 11i
/* noproto.c */
#include <stdio.h>
int main() {
long a;
a = foo();
printf ("The returned value is: 0x%lx\n", a);
return 0;
}
/* foo.c */
long foo() {
return 0x1122334455667788L;
}
% cc +DD64 noproto.c foo.c
% ./a.out
The returned value is: 0x55667788
% cc +tru64 +DD64 noproto.c foo.c
% ./a.out
The returned value is: 0x1122334455667788
You can check whether your application calls functions without prototypes by
compiling with the -warnprotos option with the Compaq C compiler, as shown
in Example 4–4.
Example 4–4: Using the -warnprotos Option on Tru64 UNIX
% cc -c -warnprotos noproto.c
cc: Warning: noproto.c, line 6: In this statement, "foo" is
called with no arguments and it has no prototype. (warnimplfunc1)
4.1.6.2 Passing Types Smaller Than Expected
Older applications sometimes pass integer types that are smaller than the type
expected by the called routine. This does not cause problems on Tru64 UNIX
because in order to take full advantage of the 64-bit processor, the Tru64 UNIX
compilers always use 64-bit values for passing arguments to functions. Any
conversion of argument values to smaller types is expected to be performed
Compilers
4–5
explicitly by the calling routine. The HP-UX 11i compilers do not sign extend
integer-type arguments, which may cause older applications to behave differently
on the two platforms.
Example 4–5 shows two potential problems that can occur on HP-UX 11i.
The first is that parameters passed in memory (the ninth and higher) are not filled
to 64 bits, leaving garbage in the higher bits (see Example 4–6). This only occurs
on PA-RISC platforms. The HP ANSI C compiler for Itanium®-based systems has
been modified so that memory parameters are treated the same as parameters
in registers.
Second, arguments passed in registers are not sign extended. When compiled
with -DSIGN="-" -O0 to pass negative arguments and disable optimization,
Example 4–7 shows that arguments passed in registers are zero extended, not sign
extended. To check for these types of problems in your application, use the lint(1)
utility on Tru64 UNIX to detect where arguments of a type other than expected
are being passed.
Example 4–5: Passing Types Smaller Than Expected
/* main.c */
#ifndef TYPE
#define TYPE int
#endif
#ifndef SIGN
#define SIGN
#endif
void sub (TYPE, TYPE, TYPE, TYPE, TYPE, TYPE, TYPE, TYPE, TYPE);
void sub1 (TYPE, TYPE, TYPE, TYPE, TYPE, TYPE, TYPE, TYPE, long);
int main () {
TYPE a1 = SIGN 1;
TYPE a2 = SIGN 2;
TYPE a3 = SIGN 3;
TYPE a4 = SIGN 4;
TYPE a5 = SIGN 5;
TYPE a6 = SIGN 6;
TYPE a7 = SIGN 7;
TYPE a8 = SIGN 8;
TYPE a9 = SIGN 9;
sub1(a1, a2, a3, a4, a5, a6, a7, a8, 0xdeadbeefdeadbeefL);
sub(a1, a2, a3, a4, a5, a6, a7, a8, a9);
return 0;
}
/* sub.c */
#ifndef RTYPE
#define RTYPE long
#endif
#ifndef SIGN
#define SIGN
#endif
#include <stdio.h>
void sub1 () {}
void sub (RTYPE a1,RTYPE a2,RTYPE a3,RTYPE a4,RTYPE a5,RTYPE a6,
RTYPE a7,RTYPE a8,RTYPE a9)
{
long a;
a = a1;
printf ("The value should be %d.\n", SIGN 1);
printf ("It is %ld (0x%016lx)\n", a, a);
4–6
Compilers
Example 4–5: Passing Types Smaller Than Expected (cont.)
a = a2;
printf ("The value
printf ("It is %ld
a = a3;
printf ("The value
printf ("It is %ld
a = a4;
printf ("The value
printf ("It is %ld
a = a5;
printf ("The value
printf ("It is %ld
a = a6;
printf ("The value
printf ("It is %ld
a = a7;
printf ("The value
printf ("It is %ld
a = a8;
printf ("The value
printf ("It is %ld
a = a9;
printf ("The value
printf ("It is %ld
should be %d.\n", SIGN 2);
(0x%016lx)\n", a, a);
should be %d.\n", SIGN 3);
(0x%016lx)\n", a, a);
should be %d.\n", SIGN 4);
(0x%016lx)\n", a, a);
should be %d.\n", SIGN 5);
(0x%016lx)\n", a, a);
should be %d.\n", SIGN 6);
(0x%016lx)\n", a, a);
should be %d.\n", SIGN 7);
(0x%016lx)\n", a, a);
should be %d.\n", SIGN 8);
(0x%016lx)\n", a, a);
should be %d.\n", SIGN 9);
(0x%016lx)\n", a, a);
}
Example 4–6: Arguments Passed in Memory
% cc +DD64 main.c sub.c
% ./a.out
The value should be 1. It
The value should be 2. It
The value should be 3. It
The value should be 4. It
The value should be 5. It
The value should be 6. It
The value should be 7. It
The value should be 8. It
The value should be 9. It
is
is
is
is
is
is
is
is
is
1 (0x0000000000000001)
2 (0x0000000000000002)
3 (0x0000000000000003)
4 (0x0000000000000004)
5 (0x0000000000000005)
6 (0x0000000000000006)
7 (0x0000000000000007)
8 (0x0000000000000008)
-2401053092612145143 (0xdeadbeef00000009)
Example 4–7: Arguments not Sign Extended
% cc +DD64 -DSIGN="-" -O0 main.c sub.c
% ./a.out
The value should be -1. It is 4294967295 (0x00000000ffffffff)
The value should be -2. It is 4294967294 (0x00000000fffffffe)
The value should be -3. It is 4294967293 (0x00000000fffffffd)
The value should be -4. It is 4294967292 (0x00000000fffffffc)
The value should be -5. It is 4294967291 (0x00000000fffffffb)
The value should be -6. It is 4294967290 (0x00000000fffffffa)
The value should be -7. It is 4294967289 (0x00000000fffffff9)
The value should be -8. It is 4294967288 (0x00000000fffffff8)
The value should be -9. It is -2401053088317177865 (0xdeadbeeffffffff7)
Compilers
4–7
4.1.6.3 Negative Floating-Point to Unsigned Integer Conversion
On Tru64 UNIX and HP-UX 11i on PA-RISC platforms, the conversion of
negative floating-point values to unsigned integral values is performed by
first converting to signed integral type, and then converting to unsigned and
truncating to a 32-bit value. On Itanium®-based systems, the conversion does
not go through the intermediate signed type, but instead goes directly to
unsigned through a hardware instruction.
For example, on Tru64 UNIX and PA-RISC platforms, the value -1.0 will be
converted to the largest unsigned integer. On Itanium®-based systems, the
result will be different, usually zero. The source code in Example 4–8, and the
output in Example 4–9 and Example 4–10 demonstrates this difference.
Example 4–8: Negative Floating-Point to Unsigned Integer Conversion
/* convert.c */
#include <stdio.h>
int main() {
float f = -1.0;
unsigned int i = f;
printf ("%f as unsigned int = %u\n",f,i);
return 0;
}
Example 4–9: Conversion Output on PA-RISC Matches Tru64 UNIX
% cc +DD64 convert.c
% ./a.out
-1.000000 as unsigned int = 4294967295
Example 4–10: Conversion Output on Itanium®-based Systems
% cc +DD64 convert.c
% ./a.out
-1.000000 as unsigned int = 0
4.2 C++ Compilers
The information in this section is based on the features available in Compaq
C++ Version 6.5, HP aC++ Version A.03.63 for PA-RISC, and HP aC++ Version
A.06.00 for the Itanium® processor family. All of these compilers are based on the
ANSI/ISO C++ International Standard ISO/IEC 14882. Write your code to conform
to the ANSI C++ standard for ease of porting and consistency across platforms.
The following sections discuss these compilers in more detail.
4.2.1 Language Differences
The default mode for Compaq C++ is -std ansi, which supports some commonly
used extensions and is not as strict as the standard. Try using the -std
strict_ansi option to flag any nonstandard code. Note that this option also sets
-pure_cname. You may need to use the -nopure_cname option if your application
calls any C functions that are not specified by the C++ International Standard. For
HP aC++, use the -Aa option to enable ANSI C++ Standard features like Koenig
lookup and standard scoping rules for variables declared in conditional statements
like for loops.
4–8
Compilers
By default, Compaq C++ and HP aC++ for PA-RISC platforms both use the
pre-standard version of iostreams. On PA-RISC systems, the -AA compiler
option may be specified to use the 2.0 C++ Standard Library.
By default, HP aC++ for the Itanium® processor family uses the 2.0 C++
Standard Library, which includes the standard conforming (templatized)
iostream library. The -AP compiler option may be specified to use the older
1.2.1 C++ Standard Library.
Table 4–4 summarizes these options and specifies the defaults for each platform.
Table 4–4: C++ Options to Select iostreams Library
iostreams library
Compaq C++
HP aC++
Pre-standard
-D__NO_USE_STD_IOSTREAM
(default)
-AP (PA-RISC default)
Standard
-D__USE_STD_IOSTREAM
or
-std strict_ansi
or
-std strict_ansi_errors
-AA (Itanium® processor
family default)
___________________
Common Mistake
___________________
The -AA and -AP options are mutually exclusive and all objects and
libraries (including third-party libraries) must be consistently built
with one or the other. Mixing object files within an executable is not
supported.
In the default mode, the HP aC++ compiler for Itanium®-based systems will
generate a warning that <iostream.h> is being replaced by <iostream>, as
shown in Example 4–11. The same warning is generated on PA-RISC systems
when the -AA option is used.
Example 4–11: <iostream.h> Replaced By <iostream>
/* hello.C */
#include <iostream.h>
int main() {
cout << "Hello world" << endl;
}
% aCC hello.C
Warning 890:"/opt/aCC/include_std/iostream_compat/iostream.h",
line 4 # #warning <iostream.h> is being replaced by
<iostream> followed by "using namespace std;"
For HP aC++ on both PA-RISC and Itanium®-based systems, explicitly specifying
-AA also sets -Wc,-ansi_for_scope,on and -Wc,-koenig_lookup,on. The
-ansi_for_scope option is off by default. This option disables the standard
scoping rules for variables declared in a for statement. This is different than the
Compaq C++ compiler, which enables the standard scoping rules by default. For
example, Example 4–12 compiles successfully with Compaq C++, but generates an
error with HP aC++ unless -Wc,-ansi_for_scope,on is set.
Compilers
4–9
Example 4–12: Scoping Rules for Variables in a for Statement
/* forloop.C */
int main() {
int sum = 0;
for (int k = 0; k!=100; ++k) /* line 4 */
sum += k;
for (int k = 100; k!=0; k--) /* line 6 */
sum += k;
}
% aCC forloop.C
Error 173:"forloop.C", line 6# Redefined symbol ’k’; previously
defined at ["forloop.C" line 4].
% aCC -Wc,-ansi_for_scope,on forloop.C
%
The following functionality, defined in the ANSI/ISO C++ International Standard,
is not yet supported in the HP aC++ compilers:
•
•
Template features:
–
Separation model for template compilation (export keyword)
–
Template template parameters (available on Itanium®-based systems,
but not on PA-RISC)
–
Omission of template parameter names (available on Itanium®-based
systems, but not on PA-RISC)
Support for universal character sequences (\uxxxx)
All of these features are supported by Compaq C++ with the exception of the
export keyword for templates. You may need to modify your application if it
takes advantage of features in the standard that are not yet available with the
HP aC++ compiler.
4.2.2 C++ Compiler Options
___________________
Common Mistake
___________________
The HP aC++ compiler default is to produce 32-bit objects. To compile in
64-bit mode, use the +DD64 command-line option.
_____________________
Best Practice
_____________________
By default, the Compaq C++ compiler generates instructions that are
appropriate for all Alpha processors (-arch generic). On PA-RISC
platforms, the default is to generate instructions for the architecture of
the system where the compilation is performed. If your application will
need to run on both PA-RISC 1.1 and 2.0 platforms, then compile with the
+DAportable option.
Both the Compaq C++ and HP aC++ compilers allow the passing of command-line
options through environment variables. The Compaq C++ compiler reads the
DEC_CXX environment variable for additional command-line options. The
equivalent environment variable for the HP aC++ compiler is CXXOPTS.
See Appendix B for a complete list comparing the Compaq C++ and HP aC++
compiler switches.
4–10
Compilers
4.2.3 Preprocessor Macros
Table 4–5 lists the preprocessor macros that are defined by the C++ compilers.
Compaq C++ defines __unix__ and __unix; HP aC++ only defines __unix. The
_ILP32 macro is the default on HP-UX 11i; using the +DD64 option will cause
__LP64__ and _LP64 to be defined instead.
Table 4–5: C++ Preprocessor Macros
Compaq C++
HP aC++ (for PA-RISC)
HP aC++ (for Itanium®
Processor Family)
__alpha
__hppa
__ia64
__arch64__
_ILP32 or _LP64
_ILP32 or _LP64
__digital__
Not Available
Not Available
__osf__
__hpux
__hpux
__unix__ and __unix
__unix
__unix
__DECCXX_VER=<version>
__HP_aCC=<version>
__HP_aCC=<version>
_LONGLONG
Not Availablea
Not Availablea
_SYSTYPE_BSD
Not Available
Not Available
Not Available
Not Available
_BIG_ENDIAN
a _INCLUDE_LONGLONG is defined when the -ext option is used.
4.2.4 Compiling C Source Files
Compaq C++ treats files ending in the suffix .c as C source files, and invokes
the C compiler to process these files. The -x cxx option must be specified to
compile them in C++ mode. By default, HP aC++ treats files with the .c suffix
as C++ source files, so there is no need for an option similar to -x cxx. If you
are currently compiling C source files with Compaq C++, and want them to be
compiled as C source files by HP aC++, use the -Ae option to invoke HP aC++
as an ANSI C compiler.
4.2.5 Template Instantiation
The Compaq C++ compiler provides automatic template instantiation at compile
time. Necessary templates are automatically instantiated by the compilation of
the source file that needs them and has access to the template definitions. The
compiler writes instantiation files to a directory called the repository.
The HP aC++ compiler uses a similar mechanism, which it calls compile-time
instantiation. One difference is that it writes instantiations to the object files in
which the template is used, rather than to a separate repository (similar to the
-tused switch for Compaq C++). This may result in duplicate instantiations in
multiple object files, but the linker will arbitrarily choose only one instantiation for
the resulting executable or shared library.
The Compaq C++ compiler provides three methods to instantiate templates
explicitly:
•
Using the pragma directives
•
Using explicit template instantiation syntax
•
Using the command-line option method
The pragma instantiation directives are not implemented in the HP aC++
compiler, so Compaq C++ applications taking advantage of these directives (see
Example 4–13) will need to be modified to use explicit template instantiation
syntax, as shown in Example 4–14.
Compilers
4–11
Example 4–13: Template Instantiation with a Pragma Directive
/* pragma_template.cxx */
template <class T> void sort (T *array)
{
/* body of sort */
}
#pragma define_template sort<int>
% aCC -c pragma_template.cxx
Warning 67: “pragma-template.cxx”, line 6 # Invalid pragma
name: ’define_template’ (ignored).
For HP aC++, a warning will be generated that define_template is an invalid
pragma name. The #pragma directive has to be replaced with the ANSI C++
Standard syntax, as shown in Example 4–14.
Example 4–14: Standard Template Instantiation Syntax
/* standard_template.cxx */
template <class T> void sort (T *array)
{
/* body of sort */
}
template void sort<int>(int *);
4.2.6 typename Keyword
Compaq C++ requires use of the typename keyword only when compiling with
-std strict_ansi. HP aC++ enforces the use of the typename keyword. A
qualified name that refers to a type and that depends on a template argument must
be prefixed by the typename keyword to indicate that the qualified name denotes a
type. Programs that have not been compiled using strict ANSI compliance mode
on Tru64 UNIX may need to be modified to use this keyword. In Example 4–15,
the code will compile successfully with Compaq C++ with the default switch -std
ansi, but will fail to compile with HP aC++. HP aC++ will generate the error
message shown in Example 4–15.
Example 4–15: typename Keyword
/* typename.cxx */
template <class T> class C { T::A foo( ); };
% aCC -c typename.cxx
Error 419: “typename.cxx”, line 2# ’A’ is used as a type,
but has not been defined as a type.
Adding the typename keyword will allow this to compile successfully under aC++ :
template <class T> class C { typename T::A foo( ); };
4.3 Java
Java SDKs, which implement the Java 2 SDK v1.4.2, are available for both Tru64
UNIX and HP-UX 11i. The current Java implementation for HP-UX 11i is SDK
1.4.2.07, which supports the HotSpot virtual machine.
4–12
Compilers
___________________
Common Mistake
___________________
The Java runtime environment on HP-UX 11i is 32-bit by default. Use
the +d64 option to run the 64-bit HotSpot VM (available with SDK
1.4.1 or later).
On HP-UX 11i, Java resides in the /opt/java<version>/bin/ directory by
default. To check the version of Java currently installed, enter:
% java -version
java version "1.4.1.03"
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.4.1.03-030630-19:37)
Java HotSpot(TM) Server VM
(build 1.4.1 1.4.1.03-030701-03:26-IA64N IA64, mixed mode)
For updated information on Java software and documentation, see:
http://www.hp.com/go/java
4.3.1 Java Tuning Information
Many Java applications will run with the default set of kernel parameters on
HP-UX 11i, but resource-intensive applications may require the customization of
kernel parameters. The HPjconfig tool may be used to obtain recommendations for
certain kernel parameters. For more information and to download the HPjconfig
tool, see:
http://www.hp.com/products1/unix/java/java2/hpjconfig/
4.4 FORTRAN Compilers
This section compares Compaq Fortran Version 5.5 and HP Fortran Version 2.9.
Both Compaq Fortran and HP Fortran conform to the Fortran 90 and Fortran 95
standards. In addition, both compilers support a full OpenMP implementation. HP
Fortran v2.9 has been significantly enhanced with many Compaq Fortran features.
For a complete list of new features, see the HP Fortran v2.9 reference pages and
release notes. For a list of Compaq Fortran features that are not available in HP
Fortran, see the Porting Compaq Fortran applications on Tru64 UNIX to HP-UX
white paper:
http://devrsrc1.external.hp.com/STKT/portguides.html
4.4.1 Language Differences
Compaq Fortran is highly compatible with FORTRAN 77. While HP Fortran is
compatible with standard-conforming FORTRAN 77, some command-line options
and nonstandard extensions in FORTRAN 77 programs may have to be changed to
compile and execute correctly under HP Fortran. For more information, see the
chapters on migrating to HP Fortran and porting to HP Fortran in the HP Fortran
Programmer’s Guide:
http://docs.hp.com/en/dev.html#Fortran
Compaq Fortran includes a number of extensions to the Fortran 95 Standard,
including support for the High Performance Fortran Language Specification.
Compaq Fortran also includes the Compaq Extended Math Library (CXML). HP
Fortran is complemented by the high-performance math run-time library and the
linear algebra package (assembly coded).
Compilers
4–13
4.4.2 FORTRAN Compiler Options
___________________
Common Mistake
___________________
The HP Fortran compiler default is to produce 32-bit objects. To compile
in 64-bit mode, use the +DD64 command-line option.
_____________________
Best Practice
_____________________
By default, the Compaq Fortran compiler generates instructions that
are appropriate for all Alpha processors (-arch generic). On PA-RISC
platforms, the default is to generate instructions for the architecture of
the system where the compilation is performed. If your application will
need to run on both PA-RISC 1.1 and 2.0 platforms, then compile with the
+DAportable option.
HP Fortran v2.9 requires the use of the /opt/fortran90/tru64/f90 driver or
the +cfc option with the default f90 driver to access the newly-implemented
Compaq Fortran options. For a list of the new options, see the HP Fortran
reference pages and release notes. The release notes are located at:
http://docs.hp.com/en/dev.html#Fortran
See Appendix C for a complete list comparing the Compaq Fortran and HP Fortran
compiler switches.
4.5 Assembler
HP-UX 11i provides an assembler (/usr/ccs/bin/as) for low-level
processor-specific development. HP recommends that you use a higher level
language (C, C++, FORTRAN) whenever possible for development. Using a
high-level language allows for more portability and potential for code reuse.
The HP-UX 11i C compilers also provide for the use of inline assembler
with the inclusion of <machine/inline.h> on PA-RISC systems and
<machine/sys/inline.h> on Itanium®-based systems. This is also supported for
C++ on Itanium®-based systems. For more information on using inline assembler
on Itanium®-based systems, see the Inline Assembly for Itanium®-based HP-UX
document:
http://h21007.www2.hp.com/dspp/files/unprotected/Itanium/
inline_assem_ERS.pdf
Using inline assembler allows you to maintain a higher level of portability while
accomplishing tasks that may not be part of the language. To ensure easier
transitions in the future, document any use of the inline assembler and put it
under preprocessor control by using the #if directives.
For more information on the HP-UX 11i v1 assembler, see the HP Assembler
Reference Manual:
http://docs.hp.com/en/dev.html#Assembler
For more information on the HP-UX 11i v2 assembler, see the Itanium®
Architecture Assembly Language Reference Guide:
http://developer.intel.com/software/products/
opensource/tools1/tol_whte2.htm
4–14
Compilers
4.6 Mixed-Language Programming
This section discusses some differences between Tru64 UNIX and HP-UX 11i for
mixed-language programming.
4.6.1 FORTRAN Trailing Underscores
Both Compaq Fortran and HP Fortran (on the Itanium® processor family and for
64-bit objects on PA-RISC) append a trailing underscore character to external
user-defined names by default. For mixed-language programming environments, it
can be useful to suppress the underscore. Compaq Fortran provides the -assume
nounderscore option for this purpose. The equivalent option for HP Fortran is
+noppu.
4.6.2 Compiling Mixed-Language Programs
The Compaq Fortran driver will recognize C source files and pass them to the
Compaq C compiler to create an object file. On HP-UX 11i, the C source file must
first be compiled by the C compiler, and then the resulting object can be linked with
HP Fortran objects using the f90 driver. Attempting to compile C source with the
f90 driver will generate an error, as shown in Example 4–16 and Example 4–17.
Example 4–16: Compiling Mixed-Language Programs on PA-RISC
% f90 test.f90 sub.c
/usr/ccs/bin/ld: sub.c: Not a valid object file
(invalid system id)
% cc -c sub.c
% f90 test.f90 sub.o
Example 4–17: Compiling Mixed-Language Programs on the Itanium® Processor
Family
% f90 test.f90 sub.c
ld: Mismatched ABI (not an ELF file) for sub.c
% cc -c sub.c
% f90 test.f90 sub.o
4.6.3 Linking Mixed-Language Programs
When linking a C program that calls FORTRAN routines on HP-UX 11i, you have
to include the HP Fortran run-time library by adding -lcl to the cc command
line, as well as any required HP Fortran run-time libraries and their dependencies.
For example, -lF90 depends on -lm, -lcps, and -lpthread.
Compaq Fortran requires the use of the -nofor_main option when linking a C
program that calls a FORTRAN subprogram. The HP Fortran compiler does not
have this requirement, so there is no need for this option on HP-UX 11i.
4.6.4 Directives for Mixed-Language Calls
Compaq Fortran provides the DEC$ ALIAS and DEC$ ATTRIBUTES directives to
simplify mixed-language calls. The $HP$ ALIAS directive in HP Fortran provides
some of the same functionality as the two Compaq Fortran directives. You can use
the $HP$ ALIAS directive to specify the case that FORTRAN should use when
calling an external name. Its also allows you to establish the argument-passing
Compilers
4–15
modes for each parameter in a particular routine. Consider a C function with a
mixed-case name, with the following prototype declaration:
void FooBar(int *ptr, int iarray[100], int i);
Here is the $HP$ ALIAS directive for the FORTRAN program that calls FooBar( ):
!$HP$ ALIAS foobar = ’FooBar’(%REF, %REF, %VAL)
For more information, see the chapter Calling C routines from HP Fortran in
the HP Fortran Programmer’s Guide:
http://docs.hp.com/en/dev.html#Fortran
4.7 Controlling Namespaces
Both Tru64 UNIX and HP-UX 11i provide definition environments for interfaces
that conform to industry standards, as well as proprietary interfaces (see
Table 4–6). The -D compiler option’s arguments control the different namespaces
supported by the header files that are supplied by the operating system. For more
information on these definition environments, see the standards(5) reference page
on Tru64 UNIX and the stdsyms(5) reference page on HP-UX 11i.
Table 4–6: Compiler Definitions for Industry Standards
Tru64 UNIX Definition
HP-UX 11i Definition
Standard
-D_OSF_SOURCE (Default)
-D_HPUX_SOURCE (Default for-Ae)
Proprietary
interfaces
-D_XOPEN_SOURCE=500
-D_XOPEN_SOURCE=500 or
-DUNIX_STD=98
UNIX 98
-D_XOPEN_SOURCE_EXTENDED
-D_XOPEN_SOURCE_EXTENDED
UNIX 95
-D_XOPEN_SOURCE (Default)
-D_XOPEN_SOURCE
XPG4
-D_POSIX_SOURCE
-D_POSIX_SOURCE
POSIX
-D_ANSI_C_SOURCE
Default for -Aa and c89
ANSI C
By default, _XOPEN_SOURCE and _OSF_SOURCE are defined for the C compiler
on Tru64 UNIX when no other compilation macros are defined. On HP-UX 11i,
_HPUX_SOURCE is defined when the -Ae compiler option is specified, which is the
default.
_________________________
Note
_________________________
Use of the C compiler option -Aa will result in only the ANSI C
namespace being defined on HP-UX 11i. This is different from Tru64
UNIX where the least restrictive namespace (_OSF_SOURCE) is used by
default. C compilations that use the -Aa option will need to explicitly
define the appropriate namespace if the source code refers to interfaces
that are outside of the ANSI C namespace. In Example 4–18, the
O_CREAT flag for the open(2) system call is not defined when compiling
with -Aa. Adding -D_POSIX_SOURCE to the compile line resolves the
problem.
Example 4–18: Define Namespace with -Aa Option on HP-UX 11i
/* open.c */
#include <fcntl.h>
#include <stdio.h>
main( int argc, char *argv[])
4–16
Compilers
Example 4–18: Define Namespace with -Aa Option on HP-UX 11i (cont.)
{
int fd1;
fd1 = open( "testfile", O_CREAT|O_RDWR, 0666 );
if( fd1 < 0) { perror("open testfile"); exit( 1);}
printf( "file descriptor %d opened\n", fd1);
}
% cc -Aa open.c
Error 172: “open.c”, line 9 # Undeclared variable ’O_CREAT’.
% cc -Aa -D_POSIX_SOURCE open.c
Figure 4–1 shows the namespaces for both operating systems, and demonstrates
that each namespace is a superset of the ones that it surrounds.
Figure 4–1: Namespaces
Tru64 UNIX
HP-UX
OSF
HP-UX
X/Open
X/Open
POSIX
POSIX
ANSI C
ANSI C
ZK-1983U-AI
4.8 References
HP C Compiler (PA-RISC)
•
For the HP C Online Help and Release Notes, see:
http://docs.hp.com/en/dev.html#C
HP aC++/HP ANSI C Compiler
•
For the HP aC++/HP ANSI C Online Programmer’s Guide and Release Notes,
see the documentation link at the HP aC++ Home Page:
http://www.hp.com/go/hpc++
Java
•
For updated information on Java software and documentation, see:
http://www.hp.com/go/java
FORTRAN
•
HP Fortran Programmer’s Guide:
http://docs.hp.com/en/dev.html#Fortran
•
Porting Compaq Fortran applications on Tru64 UNIX to HP-UX:
http://devrsrc1.external.hp.com/STKT/portguides.html
Compilers
4–17
5
Linkers and Loaders
This chapter discusses the differences in the linker and run-time loader. For more
information on these topics, see the reference pages and the HP-UX Linker and
Libraries User’s Guide. Unless explicitly stated all information in this chapter
pertains to the PA-RISC 64-bit, Itanium® 32-bit, or the Itanium® 64-bit linkers and
loaders. The 32-bit PA-RISC linker has significant differences from both Tru64
UNIX and the other environments available under HP-UX 11i.
_________________________
Note
_________________________
The 32-bit PA-RISC linker is significantly different from the other linkers. As
a result is it not covered in great detail in this chapter. Unless otherwise noted,
the content in this chapter does not include the 32-bit PA-RISC environment.
For information on this linker, see the HP-UX Linker and Libraries User’s
Guide, available from:
http://docs.hp.com/en/hpux11iv2.html
Note that a newer version of this document is available by using the ld
+help command.
5.1 Link Editor
HP recommends using the compiler to perform the final link. This is because
the compiler may silently attach additional libraries (libc, libcxx, libexc,
and others) or options that you do not explicitly provide on your link line. For
example, the Compaq C++ compiler adds an implicit -rpath to the link line as well
as several libraries. In cases where you need to provide special options or more
information, you can use the link editor (ld) directly.
The term linker is generally used when discussing the link editor. The following
sections describe the link editor in more detail.
5.1.1 Tru64 UNIX Migration Environment for HP-UX
The Tru64 UNIX Migration Environment for HP-UX includes a linker driver to
translate some of the Tru64 UNIX linker options to HP-UX 11i linker options.
This driver is a temporary measure to assist in the migration effort. You should
attempt to migrate your build environment using the driver and the information
contained in this guide to a native HP-UX 11i environment.
In addition to the standard Tru64 UNIX options and environment variables, the
linker driver also recognizes the following:
Linkers and Loaders
5–1
TRU64_MIGRATION_LIBS
When not set or set to anything other than
the empty string or zero (0), the linker
driver will add the Tru64 UNIX migration
libraries to your link line. These libraries
provide a limited set of Tru64 UNIX APIs.
For more information on these libraries see
Section 13.1.1.
DEC_LD
Lets you establish a set of link options that
are added to subsequent invocations of the
linker driver. This variable parallels the
functionality of the DEC_CC. The DEC_LD
environment variable provides a convenient
mechanism for adding -port* options
without modifying makefiles.
-port_info
Reports actions taken to translate the link
line and problems that might require user
intervention. Reports the translated link
command.
-port_info_only
Same as -port_info, but the link command
is not executed.
-port_command
Reports the translated link command.
-port_command_only
Same as -port_command, but the link
command is not executed.
The following Tru64 UNIX linker options are silently ignored:
-d
-F
-Kdir
-S
-VS num
-b
-B num
-f fill
-gnum
-oldstyle_liblookup
-om
The following Tru64 UNIX linker options are ignored and generate user warnings:
-N
-check_registry_file location
-fixed
-n
-nN
-update_registry location
-set_version version-string
-exact_version
The remaining options are processed internally by the driver and translated into
one or more arguments on the new link line. More information on the Tru64 UNIX
Migration Environment for HP-UX is available from the Tru64 UNIX Transition
Web site:
http://www.hp.com/go/tru64appmigration
5.1.2 Passing Options To The Linker
There are several ways to pass options to the linker on HP-UX 11i. Like Tru64
UNIX, you can pass them through the compiler using -Wl,optionlist, where
optionlist is a comma-delimited list. The -Wl option can appear several times, but
related linker options should appear in one list rather than specifying multiple -Wl
options. The HP-UX 11i linker also processes the LDOPTS environment variable for
additional options. Options placed in LDOPTS are prepended to the link line.
5–2
Linkers and Loaders
_____________________
Best Practices
_____________________
The Tru64 UNIX -input option provides an alternative source for
command options when the command line becomes too long. HP-UX 11i
provides a similar mechanism using the -c option.
5.1.3 Environment Variables
HP-UX 11i provides the LPATH environment variable, which allows you to
completely override the default search path of the linker. While this is a linker
variable, it does affect the loader by setting the application’s rpath. Specifying
LPATH=/dev/null will result in the linker behaving like the -L option with no
argument on Tru64 UNIX. HP-UX 11i automatically stores the contents of LPATH
as the library’s rpath if no explicit +b is specified on the link line.
5.1.4 Command-Line Options
Some linker options are the same in HP-UX 11i and Tru64 UNIX; others are
significantly different. Some options have a direct mapping, and others are not
available or require a significant reworking of your development environment.
You can use the linker driver for the Tru64 UNIX Migration Environment for
HP-UX (see Section 5.1.1) to provide a mapping of your Tru64 UNIX link line to an
approximately equivalent HP-UX 11i link line. For a complete list of Tru64 UNIX
options and their HP-UX 11i equivalents, see Appendix D. For details on a specific
option, see the ld(1) reference pages for each operating system.
5.1.5 Library Search Order
The Tru64 UNIX and HP-UX 11i linkers use different search algorithms and
paths when locating libraries. When used to perform the link, compilers on
both operating systems augment the default paths with additional paths for
language-specific run-time support libraries. The default paths searched by the
linkers are shown in Table 5–1.
Table 5–1: Library Search Paths
Environment
Search Path
Tru64 UNIX
/usr/shlib/
/usr/ccs/lib/
/usr/lib/cmplrs/cc/
/usr/lib/
/usr/local/lib/
/var/shlib/
32-bit Itanium® applications
/usr/lib/hpux32/
/usr/ccs/lib/hpux32/
64-bit Itanium® applications
/usr/lib/hpux64/
/usr/ccs/lib/hpux64/
32-bit PA-RISC applications
/usr/lib/
/usr/ccs/lib/
64-bit PA-RISC applications
/usr/lib/pa20_64/
/usr/ccs/lib/pa20_64/
On both Tru64 UNIX and HP-UX 11i the default behavior is to bind to shared
libraries before linking in archives. The difference is in how those libraries are
located. Tru64 UNIX searches all the directories specified by the -L options, and
Linkers and Loaders
5–3
then searches the default directories for shared libraries. The linker then performs
another search for archive libraries to resolve any remaining dependencies.
The behavior on HP-UX 11i is different. The HP-UX 11i linker searches using the
same directory list (-L then the default paths) for shared libraries followed by the
archive libraries one directory at a time. Only a single pass is made through the
directory list. This behavior is similar to the -oldstyle_liblookup behavior on
Tru64 UNIX.
Applications that store all of their libraries in a single directory will not be affected
by this change in search order. However, those applications that store libraries
in multiple directories, including third-party libraries, may be affected. Use the
linker option +vtype files to determine which libraries were used. For example:
% cc -c a.c
% ar rc L1/libA.a a.o
% ranlib L1/libA.a
% cc -c b.c
% cc -b a.o -o L2/libA.so
% cc -b b.o -o L2/libB.so
% cc -LL1 -LL2 main.c -lA -lB -Wl,+vtype,files
Loading main.o:
Loading L1/libA.a[a.o]:
Loading L2/libB.so:
Loading /usr/lib/hpux32/libc.so:
Loading /usr/lib/hpux32/libdl.so.1:
Building this same sequence on Tru64 UNIX would result in a.out having
dependencies on both libA.so and libB.so. For example:
% cc -LL1 -LL2 main.c -lA -lB -rpath L1:L2
% ldd a.out
/usr/bin/ldd a.out
Main =>
a.out
libA.so =>
L2/libA.so
libB.so =>
L2/libB.so
libc.so =>
/usr/shlib/libc.so
If you do encounter this problem, explicitly specifying the library to be linked
(./L2/libA.so) or changing the order of your directory specification (-LL2 -LL1)
may resolve it.
5.1.6 Linker-Defined Symbols
The linker provides some special symbols that have meaning to the loader and
certain types of applications. The linker-defined symbols are often a result of
the object format.
All applications on Tru64 UNIX (eCOFF) use variations of the original UNIX
a.out file format.
Itanium® libraries and applications use the ELF (Executable and Linking Format),
elf(3E). There are two variants on the ELF standard, one for 32-bit memory
models (ELF32) and one for 64-bit memory models (ELF64). 64-bit PA-RISC
libraries and applications also use the ELF64 format.
The 32-bit PA-RISC applications and libraries use the SOM format.
On Tru64 UNIX the linker will generate warnings if a reserved symbol is defined
in user code; the HP-UX linker will only generate a warning if the symbol is
defined as an extern. These symbols are named to avoid collision with user code.
However, be careful when choosing symbol names. There are several points of
5–4
Linkers and Loaders
overlap between these three object formats. The following tables compare the
symbols between Tru64 UNIX and the various forms on HP-UX.
Table 5–2 lists those symbols common to all three object formats.
Table 5–2: Common Linker-Defined Symbols
Symbol
Definition
_etext, etext
First address above the text region.
_edata, edata
First address above the initialized data
region.
_end, end
First address above a program’s uninitialized
data region.
Table 5–3 list the symbols common to both the SOM and ELF format and their
Tru64 UNIX eCOFF equivalents.
Table 5–3: Common HP-UX Symbols
Tru64 UNIX
HP-UX 11i
Description
Not Available
_SYSTEM_ID, __SYSTEM_ID
Largest architecture revision
level used by any compilation
unit.
_ftext
__text_start
Start address of the text region.
_fdata
__data_start
First address of the initialized
data region.
__environ
_environ
Pointer to environment block.
__fstart
__fini_start
Start of .fini section.
__istart
__init_start
Start of .init section.
Table 5–4 provides a mapping of symbols on Tru64 UNIX and their HP-UX 11i
ELF equivalents.
Table 5–4: Linker-Defined ELF Symbols
Tru64 UNIX
HP-UX 11i
Description
.fini
.fini
Section name.
.data
.data
Section name.
.text
.text
Section name.
.init
.init
Section name.
.rconst
.rodata
Section name.
.sdata
.sdata
Section name.
.sbss
.sbss
Section name.
.bss
.bss
Section name.
.comment
.note
Extra information section.
_gp
__gp
Global Pointer Value.
Not Available
__init_end
End of .init section.
Not Available
__fini_end
End of .fini section.
Linkers and Loaders
5–5
Table 5–4: Linker-Defined ELF Symbols (cont.)
Tru64 UNIX
HP-UX 11i
Description
__tlsbsize, __tlsdsize
__TLS_SIZE, __tls_size
Size of Thread Local Storage
segment. Tru64 UNIX splits
the sizes of initialized and
uninitialized data into different
elements; HP-UX 11i provides
both sizes combined.
_DYNAMIC
_DYNAMIC
Address of a shared object’s
dynamic header table.
Not Available
__unwind_start,
__unwind_end
Start/End of unwind table.
Not Available
_FPU_STATUS
Initial value of FPU status
register.
Table 5–5 lists those symbols reserved by the SOM format and any equivalence
with Tru64 UNIX symbols.
Table 5–5: Linker-Defined SOM Symbols
Tru64 UNIX
HP-UX 11i
Description
Not Available
FP_STATUS, _fp_status
Initial value of FPU status
register.
Not Available
__profil_size
Value specified by the
+profilebucketsize linker
option.
Not Available
___stack_zero
Internal stack protection.
Not Available
__dld_path
Value specified by the +interp
linker option.
__tlsbsize, __tlsdsize __tdsize
Size of Thread Local Storage
segment. Tru64 UNIX splits
the sizes of initialized and
uninitialized data into different
elements; HP-UX 11i provides
both sizes combined.
Not Available
__tdata_addr
Address of thread data.
Not Available
__tdata_sz
Size of thread data.
Not Available
_LB_BRANCH_STRINGS
Marks beginning of profiling
subspace.
Not Available
_LB_BRANCH_STRINGS_END
Marks end of profiling subspace.
Not Available
_CPU_REVISION
CPU information.
Not Available
_CPU_KEYBITS_1
CPU information.
Not Available
_FPU_MODEL
FPU information.
Not Available
_FPU_REVISION
FPU information.
Not Available
__dld_flags
Loader flags.
Not Available
__dld_hook
Loader interface.
Not Available
__dld_list
Loader module list.
__istart
___init_start
Start of .init section.
Not Available
___init_len
Size of .init section.
__fstart
___fini_start
Start of .fini section.
Not Available
___fini_end
End of .fini section.
5–6
Linkers and Loaders
Table 5–5: Linker-Defined SOM Symbols (cont.)
Tru64 UNIX
HP-UX 11i
Description
_mcount
_mcount
Internal function.
Not Available
_clear_counters
Internal function.
Not Available
_sr4export
Internal function.
Not Available
__d_trap, __d_trap_fptr
Internal function.
Table 5–6 lists those symbols that were reserved on Tru64 UNIX and are not
available and have no equivalent on HP-UX 11i.
Table 5–6: Unavailable Tru64 UNIX Symbols
.rdata
_fbss
.lit4
.lit8
eprol
_ftlsinit
__tlskey
__tlsoffset
_DYNAMIC_LINK
_BASE_ADDRESS
_GOT_OFFSET
_procedure_table
_procedure_table_size
_procedure_string_table
_cobol_main
_fpdata
_fpdata_size
_gpinfo
_ebssa
a Same as _end
5.1.7 Weak Symbol Support
The object file formats on both Tru64 UNIX and HP-UX 11i provide support for
alternate names with lower binding precedence. On Tru64 UNIX these entries are
referred to as weak symbols. Section 13.3.4 discusses this topic in more detail.
5.1.8 Uninitialized Global Data
The resolution of uninitialized global data elements differs between the Tru64
UNIX and HP-UX 11i linkers. Tru64 UNIX will treat uninitialized global data
elements as zero-initialized “weak” elements. If there is no other definition
available, then the element will be used for symbol resolution. If the symbol is
defined and initialized in the executable or another library, then all references will
resolve to the external definition at run time.
Because no standard specifies how the linker will handle this situation, relying
on this behavior is highly nonportable. Use of uninitialized globals is frequently
the cause of duplicate symbol warnings when porting code. Header files that
are included in multiple locations and source files need to be checked for global
variable definitions using this method of externalization.
Applications requiring external data element resolution must declare the element
as an extern. Those applications that rely on the preemptive design available on
Tru64 UNIX will need to be changed. It may be possible to implement similar
behavior to Tru64 UNIX by utilizing weak symbols (see Section 13.3.4) or dynamic
symbol resolution by using dlsym( ) (see Section 13.2.9). Example 5–1 shows
three source files that rely on how the linker handles uninitialized global data.
How this situation is handled on Tru64 UNIX and HP-UX 11i is discussed in detail.
Linkers and Loaders
5–7
Example 5–1: Uninitialized Global Data
% cat a.c
int glob; /* Uninitialized global symbol */
void a()
{
printf("\tA glob is %d\n", glob);
}
% cat b.c
int glob=1; /* Initialized global symbol */
void b()
{
printf("\tB glob is %d\n", glob);
}
% cat main.c
int main(int argc, char* argv[])
{
a();
b();
}
When these three files are compiled and run on Tru64 UNIX, the result is:
%
%
%
%
%
cc -c main.c
cc -shared a.c -o libA.so
cc -shared b.c -o libB.so
cc main.o -L. -rpath . -lA -lB -o test
./test
A glob is 1
B glob is 1
On HP-UX 11i the compiler, linker, and run-time loader interaction results in
multiple possible results for applications and libraries relying on this nonstandard
behavior.
HP-UX 11i on PA-RISC-based Systems (32-Bit)
With respect to the handling of unitialized globals, the PA-RISC 32-bit
compilers and run-time environment are the closest to Tru64 UNIX.
For applications using only one module, the variable is treated as
initialized to zero (0) and will be used to resolve all references.
In cases where the application involves multiple libraries with more
than one definition of the symbol in question, the initialized definition
will be used for all symbol references, regardless of link order. For
example:
% cc main.o
% test1.32
A glob
B glob
% cc main.o
% test2.32
A glob
B glob
5–8
Linkers and Loaders
-L. -Wl,+b,. -lA -lB -o test1.32
is 1
is 1
-L. -Wl,+b,. -lB -lA -o test2.32
is 1
is 1
HP-UX 11i on PA-RISC-based Systems (64-Bit)
In the PA-RISC 64-bit environment, uninitialized global data
references are implicitly initialized to zero (0) and treated as any other
initialized global data. This behavior is consistent with other SVR4
implementations.
In cases with only one symbol definition, all references will resolve to
that one symbol. In cases where multiple libraries provide a definition,
final symbol resolution will depend on link order. For example:
% cc +DD64 main.o -L. -Wl,+b,. -lA -lB -o test1.64
% test1.64
A glob is 0
B glob is 0
% cc +DD64 main.o -L. -Wl,+b,. -lB -lA -o test2.64
% test2.64
A glob is 1
B glob is 1
HP-UX 11i on Itanium®-based Systems
On Itanium®-based systems both the 32-bit and 64-bit environments
handle uninitialized global data the same way. They are externally
resolvable based on link order.
In situations where there is only one symbol definition provided, the
application will treat that definition as initialized to zero (0) and all
references will resolve to that symbol. For applications in which
there are multiple libraries containing definitions, the final symbol
resolution is link order-dependent. For example:
% cc +DD64 main.o -L. -Wl,+b,. -lA -lB -o test1.64
% test1.64
A glob is 0
B glob is 1
% cc +DD64 main.o -L. -Wl,+b,. -lB -lA -o test2.64
% test2.64
A glob is 1
B glob is 1
Note that while link order-dependent the results can be different than
on the PA-RISC 64-bit environment. For performance reasons, the
compilers on Itanium®-based systems will always use initialized data
references within a compilation unit. You can override this behavior
on a per symbol basis with either a compiler option (-Bextern=glob)
or a pragma (#pragma extern glob), where glob is the name of the
symbol you want to be preemptable. For example:
% cc +DD64 -Bextern=glob -b -o libB.so b.c
% cc +DD64 main.o -L. -Wl,+b,. -lA -lB -o test1.64
% test1.64
A glob is 0
B glob is 0
The only portable solution to this problem is that the reference in a.c to glob
must be made externally resolvable only through the C keyword extern:
extern int glob; /* Reference to external variable */
However, this may not be the exact behavior expected as a.c no longer provides
any definition of glob and it must be resolved externally.
5.1.9 Linker Optimizations
Using linker optimizations can often reduce the size of your application as well
as improve performance. Tru64 UNIX provides multiple levels (-O[0123]) of
Linkers and Loaders
5–9
linker optimization. The current HP-UX 11i v2 linker provides only one link-time
optimization: dead procedure and data elimination.
___________________
Common Mistake
___________________
When linking using the compilers on Itanium®-based systems, compiler
versions prior to 5.50 enable the +Oprocelim option at all optimization
levels, including debug. It can be explicitly disabled by specifying
+Onoprocelim on the compile or link line. Beginning with the 5.50,
compilers the +Oprocelim is only enabled at -O2 or higher.
Dead procedure elimination can result in significantly smaller images by removing
unreferenced procedures from your application. However, not all dead procedures
should be eliminated. One such case is in the use of “dead” routines for debugging;
routines that are only called from within a debugger. The +Oprocelim linker
option is enabled by default on Itanium®-based systems prior to the 5.50 compilers.
Beginning with the 5.50 compilers, this option is only enabled by default at -O2 or
higher. This option is enabled at -O4 on PA-RISC-based systems. You can explicitly
disable this option using the +Onoprocelim option on the compile line. This option
is disabled by default when linking directly with ld.
HP-UX 11i v1 provides a generic -O option, available on the HP-UX 11i v1 32-bit
linker, which enables several of the optimization options. Table 5–7 describes the
available linker optimization options.
Table 5–7: Linker Optimization Options
Option
Description
-O
Turns on linker optimizations.
+O[no]procelim
Enables [disables] the elimination of procedures that
are not referenced by the application.
+Oreusedir=dir
This option is ignored and generates a warning on
Itanium®-based systems. On PA-RISC-based systems it
specifies the name of the directory to use as the reuse
repository for the object code reuse feature.
+Oselectivepercent n
Passes the first n percent of the object files for
interprocedural optimizations.
+Oselectivesize size
This option is ignored on Itanium®-based systems. On
PA-RISC-based systems, it passes the first n routines,
where the size of n routines are approaching but less
than size for interprocedural optimizations.
+OselectiveO3
This option is ignored on Itanium®-based systems.
On PA-RISC-based systems it compiles routines not
included in the +O4 list to be compiled at +O3.
+Ostaticprediction
Meaningful only on the PA-RISC 2.0 architecture, this
option sets the branch prediction bit in the output
executable file’s auxiliary header.
+Ofastaccess
Meaningful only on 32-bit PA-RISC applications,
this option rearranges the data to further reduce the
number of ADDIL instructions.
5.2 Run-Time Linking
The run-time linker options and functionality are significantly different between
HP-UX 11i and Tru64 UNIX. On Tru64 UNIX, the loader is /sbin/loader. To
support the four application formats on HP-UX 11i v2, four loaders are used:
5–10
Linkers and Loaders
/usr/lib/hpux32/dld.so
ELF32 images for the Itanium® processor family
/usr/lib/hpux64/dld.so
ELF64 images for the Itanium® processor family
/usr/lib/dld.so
SOM images for PA-RISC
/usr/lib/pa20_64/dld.so
ELF64 images for PA-RISC
HP-UX 11i v1 does not support the Itanium® processor family and only provides
the latter two loaders.
The term loader1 is generally used when discussing the run-time linker. This helps
to distinguish it from the link editor.
The following sections describe the run-time linking process in more detail.
5.2.1 Library Resolution
To resolve any unresolved symbols in the image, the loader constructs a list
of shared objects using the information contained in the executable and its
dependencies. The search paths used to locate these libraries are different between
HP-UX 11i and Tru64 UNIX.
Tru64 UNIX
The library search order in Tru64 UNIX is:
•
If the library dependency information contains a fully qualified path, Tru64
UNIX will only attempt to load the library from that exact location. If this load
fails, then the application will not run.
•
Otherwise, the library is located by looking at the application’s rpath
(prepended by _RLD_ROOT, if it is set).
•
If not found, the loader attempts to locate the library by searching
LD_LIBRARY_PATH.
•
Finally, the loader searches the default search path (see Table 5–1), prepended
by _RLD_ROOT, if it is set.
If -no_library_replacement is used or the application is running
setuid/setgid, then _RLD_ROOT and LD_LIBRARY_PATH are both ignored.
The dynamic loading (dlopen( )) of libraries has a slightly different logic in that
the current directory is searched first, and then the algorithm previously described
is used.
1 Sometimes this is further qualified as dynamic or run-time loader.
Linkers and Loaders
5–11
Itanium® Applications and 64-Bit PA-RISC Applications
The search behavior on HP-UX 11i is different than that found on Tru64
UNIX. The following information applies only to applications built using the
default model on Itanium® processor family applications and 64-bit PA-RISC
applications. Applications built for 32-bit PA-RISC and those using the
+compat option are discussed later.
•
If the dependency information contains a fully qualified path, then the
loader searches the specified location first. If the dependency is defined
as dynamic, then if the library is not found it will continue searching.
If it is not a dynamic dependency, then failure to locate the library is a
fatal error. The dynamic property of dependencies can be changed using
chatr (see Section 5.3.2).
•
If the library has not been found and the use of environment variables is
enabled, the loader attempts to locate the library by first searching the
directories specified by LD_LIBRARY_PATH, and then it searches those
from SHLIB_PATH.
•
Only after those have been exhausted does the loader check the value of
rpath.
•
Finally, it searches the default search path.
The rpath value used to search for dependent libraries is the parent rpath,
which may be either the application or a shared library. This is different than
the behavior on Tru64 UNIX, which only uses the application’s rpath.
You can override the search of the environment variables by specifying
+noenvvar at link time. These variables are also ignored in setuid/setgid
applications. The search order can also be changed. The rpath search
can also be moved first, making it the same as Tru64 UNIX, by specifying
+rpathfirst at link time. This option is not available on HP-UX 11i v1.
PA-RISC 32-Bit and +compat Applications
The 32-bit PA-RISC linker and loader environments are unique. The linker
will store the fully qualified path of all libraries, including those specified with
the -l option as well as those implicitly included. At execution, these full
paths will be used to attempt to locate the library. If the library is dynamic
the search will continue, if not it is a fatal error. The default is for the libraries
to be dynamic.
Searching for libraries using environment variables is disabled by default
under this configuration. Under normal PA32 mode, the LD_LIBRARY_PATH
variable is not used, only the SHLIB_PATH variable is available. Under the
+compat option, the LD_LIBRARY_PATH is available. To enable the use of
environmental variables, use the +s option.
The order in which the library search continues after failing a test of the fully
qualified name depends on the order of the options on the link line. If the +b
option specifying the embedded path (rpath) appears first, then the embedded
path will be searched before any environment variables, assuming they are
enabled. If the +s option appears first, then the environment variable(s) are
searched before the embedded path.
When searching the embedded path for dependent libraries, the behavior of
PA-RISC 32-bit (PA32) applications (or those built using +compat) is different
than the other models. These applications concatenate the rpaths of all
parents back to the root application. This superset is then used to locate the
dependent library.
When searching using the environment variables PA32 application use
SHLIB_PATH only. For applications built using the +compat option both
LD_LIBRARY_PATH and then SHLIB_PATH are used to search.
After failing to locate the dependency using the embedded path and
environment variables, if enabled, the default locations are searched.
5–12
Linkers and Loaders
Common HP-UX Behavior
Use the chatr command to determine which searches are enabled and what order
they will be executed in. For example:
% chatr hello_world
hello_world:
shared executable
shared library dynamic path search:
SHLIB_PATH
disabled second
embedded path enabled
first /tmp
shared library list:
dynamic
/usr/lib/libc.2
shared library binding:
deferred
global hash table disabled
plabel caching disabled
global hash array size:1103
global hash array nbuckets:3
shared vtable support disabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
data page size: D (default)
instruction page size: D (default)
The default shared library search paths for both Tru64 UNIX and HP-UX 11i are
shown in Table 5–1. Applications built for the Itanium® processor family are not
supported on HP-UX 11i v1.
You can use the ldd(1) tool to display the library resolution information. The ldd
tool takes all the information used to load the image (environment, rpath, and
image options) and displays the resulting dependency information:
% ldd hello
libsin.so.1 =>
libc.so.1 =>
libdl.so.1 =>
/usr/lib/hpux32/libsin.so.1
/usr/lib/hpux32/libc.so.1
/usr/lib/hpux32/libdl.so.1
HP-UX 11i and Tru64 UNIX use the same method for mapping libraries into
memory. However, while Tru64 UNIX system libraries generally contain unique
starting addresses (quick-start), HP-UX 11i libraries do not. This means that
HP-UX 11i applications may take longer to start up as the loader must relocate
all the addresses in the library. Tru64 UNIX libraries are only relocated when
a collision occurs.
HP-UX 11i does provide a method to improve the load time of an application
by defining default addresses for libraries using fastbind(1). You can use the
fastbind tool or the +fb linker option to achieve load-time behavior similar to
Tru64 UNIX.
5.2.2 Address Space Layout
This section discusses the default layouts used by the loader when mapping
applications and libraries into memory. This process is significantly different
between Tru64 UNIX and HP-UX 11i. Applications that make assumptions
about where things are placed relative to each other will need to revisit those
assumptions. For example, on Tru64 UNIX the stack segment is located
immediately below the application text area.
Linkers and Loaders
5–13
_________________________
Note
_________________________
The addresses provided in these graphics are for regions and may not
match your environment completely. The addresses used are common
but are not meant as hard values; user environments and kernel
parameters can affect them.
Under Tru64 UNIX an application is given a complete 63-bit virtual address space.
The high-bit set (negative) addresses are reserved for kernel memory. Figure 5–1
shows the Tru64 UNIX 64-bit address space layout.
Figure 5–1: Tru64 UNIX 64-Bit Layout
MMAPs and
Shared Memory
Shared Library Data
0x0000 03FF C000 0000
Shared Library Text
0x0000 03FF 8000 0000
Program Heap
0x0000 0001 4000 0000
Executable Data
and BSS
Executable Text
0x0000 0001 2000 0000
0x0000 0001 1FFF FFF0
Program Stack
ZK-2024U-AI
In a TASO application (see Section 2.5.4) on Tru64 UNIX, the application is
still given a full 63-bit virtual address space. However, the loader will map the
application and its libraries into the lower 31 bits of the address space. It is still
possible to use all 63 bits. For example, mmap(2) can map files into addresses beyond
the lower 31 bits. This address would be available to all 64-bit clean portions but
unavailable to anything assuming ILP32. This is not the case on HP-UX 11i, 32-bit
applications on HP-UX 11i are restricted to using 32-bit addresses. Figure 5–2
shows the Tru64 UNIX 32-bit address space layout.
5–14
Linkers and Loaders
Figure 5–2: Tru64 UNIX 32-Bit Layout
MMAPs and
Shared Memory
Shared Library Data
0x6400 0000
Shared Library Text
0x2400 0000
Program Heap
0x1400 0000
Executable Data
and BSS
Executable Text
0x1200 0000
0x11FF FFF0
Program Stack
ZK-2023U-AI
HP-UX 11i provides the application with a full 64-bit virtual address space.
A section of this address space is reserved for use by 32-bit applications. It is
possible to use shared memory in this reserved section for communication with
32-bit applications. If a 64-bit application requests a shared memory segment
with shmget(2) using the IPC_SHARE32 option, the segment allocated will be
addressable by both 32- and 64-bit applications. A similar function is also available
for mmap( ). The mmap( ) MAP_ADDR32 option will return a 32-bit addressable
memory region. Section 13.1.3 discusses this functionality in more detail.
___________________
Common Mistake
___________________
The design of HP-UX 11i utilizes truly shared text regions in shared
libraries. As a result, placing break points in these regions is not
possible, Section 6.2.2 covers this in more detail. When debugging, the
shared library text regions are treated as normal memory-mapped files
and mapped in the shared data area. The virtual addresses will reflect
this during debugging. The addresses provided here are the default
addresses for standard operation.
Figure 5–3 shows the 64-bit address space layout for applications built for the
Itanium® processor family. Note that the stack is located in a different address
space and grows in the same direction as the stack on Tru64 UNIX. Also note that
the high-bit may be set legally in HP-UX 11i addresses in user space.
Linkers and Loaders
5–15
Figure 5–3: 64-Bit Itanium® Application Layout
Shared Memory
Shared Library Text
0xC000 0000 0000 0000
0x9FFF FFFF FFFF FFFF
Program Stack
(Fixed Size: maxssz_64bit)
Guard Page
(Fixed Size)
Register Stack
(Fixed Size)
Shared Library Data
and Private MMAPs
Program Heap
0x6000 0000 0000 0000
Executable Data
and BSS
Executable Text
0x4000 0000 0000 0000
0x0000 0000 FFFF FFFF
32-bit MMAPs
(MAP_ADDR32)
0x0000 0000 8000 0000
ZK-2026U-AI
Figure 5–4 shows the 64-bit address space layout for applications built for the
PA-RISC processor. Note that the stack is located in a different address space and
grows in the opposite direction as the stack on Tru64 UNIX. Also note that the
high-bit may be set legally in HP-UX 11i addresses in user space.
5–16
Linkers and Loaders
Figure 5–4: 64-Bit PA-RISC Application Layout
Shared Memory
Shared Library Text
Program Stack
(Fixed Size: maxssz_64bit)
0xC000 0000 0000 0000
0x8000 03FF FFFF FFFF
Shared Library Data
and Private MMAPs
Program Heap
0x8000 0001 0000 0000
Executable Data
and BSS
Executable Text
0x4000 0000 0000 0000
0x0000 0000 FFFF FFFF
32-bit MMAPs
(MAP_ADDR32)
0x0000 0000 8000 0000
ZK-2030U-AI
The HP-UX 11i 32-bit virtual address space is just that, a full 32-bit address space.
The process is completely restricted to a 32-bit environment. Unlike the Tru64
UNIX TASO environment, it is not possible to use 64-bit pointers. Figure 5–5
shows the HP-UX 11i 32-bit address space layout used by applications built for
the Itanium® processor family. Note that the stack is located in a different address
space and grows in the same direction as the stack on Tru64 UNIX. Also note that
the high-bit may be set legally in HP-UX 11i addresses in user space.
Linkers and Loaders
5–17
Figure 5–5: 32-Bit Itanium® Application Layout
Shared Memory
Shared Library Text
0xC000 0000
0x7FFF FFFF
Program Stack
(Fixed Size: maxssz)
Guard Page
(Fixed Size)
Register Stack
(Fixed Size)
Shared Library Data
and Private MMAPs
Program Heap
0x4000 0000
Executable Data
and BSS
Executable Text
0x0000 1000
ZK-2025U-AI
Figure 5–6 shows the HP-UX 11i 32-bit address space layout used by applications
built for PA-RISC processors. Note that the stack is located in a different address
space and grows in the opposite direction as the stack on Tru64 UNIX. Also note
that the high-bit may be set legally in HP-UX 11i addresses in user space.
5–18
Linkers and Loaders
Figure 5–6: 32-Bit PA-RISC Application Layout
Shared Memory
Shared Library Text
0xC000 0000
0x7FFF FFFF
Program Stack
(Fixed Size: maxssz)
Shared Library Data
and Private MMAPs
Program Heap
0x4000 0000
Executable Data
and BSS
Executable Text
0x0000 1000
ZK-2029U-AI
5.2.3 Adaptive Address Space
HP-UX 11i v2 introduces a new memory model, Adaptive Address Space
(AAS). AAS allows you to create binaries that provide you with a large address
space and more control over it. AAS is available only on HP-UX 11i v2 for
Itanium®-based servers. The AAS product is used to create a new type of
binary, MPAS, by using the chatr command or the +as mpas linker option.
For 32-bit applications, MPAS processes get the entire 4 GB of virtual
address space, all of which can be used to map any combination of shared or
private data. This is in contrast to the default address space model for 32-bit
applications on previous versions of HP-UX, which provided applications
with only 2 GB of shared address space and at most 2 GB of private address
space. MPAS processes also get some additional features that other operating
systems have had support for, but until now were not available on HP-UX 11i
v2. In particular, MPAS processes are allowed to map files into memory using
the MAP_SHARED|MAP_FILE flags, the very same offset of the file multiple
times. Each mapping is independent of the others (that is, unmapping one
will not make the others go away).
MPAS processes will have lower performance. In fact, using MPAS processes
will lower performance for the entire system, including other independent,
non-MPAS processes. Exact numbers will depend on the application itself.
32-bit MPAS applications have a flat memory model, allowing the program
to exceed the 2 GB limits of the segmented 32-bit standard model. While the
memory model is flat there are still default regions. Figure 5–7 provides a
overview of what the layout of an MPAS application might look like.
Linkers and Loaders
5–19
Figure 5–7: 32-Bit MPAS Application Layout
0xFFFF FFFF
Program Stack
(Fixed Size: maxssz)
Guard Page
(Fixed Size)
Register Stack
(Fixed Size)
Shared Library
Text & Data
MMAPs and
Shared Memory
Program Heap
Executable Data
and BSS
Executable Text
0x0000 1000
ZK-2027U-AI
In addition to being a flat memory model, the 64-bit MPAS memory model
contains an additional segment for sharing data between MPAS and default
memory model applications. The mmap( ) and shmget( ) functions both
provide access to this segment through optional flags. Memory allocated
using the MMAP_GLOBAL or IPC_GLOBAL will not incur the cost of aliasing.
Figure 5–8 shows the default regions of a 64-bit MPAS process.
5–20
Linkers and Loaders
Figure 5–8: 64-Bit MPAS Application Layout
Global Shared Memory
(MAP_GLOBAL)
0xC000 0000 0000 0000
0x9FFF FFFF FFFF FFFF
Program Stack
(Fixed Size: maxssz_64bit)
Guard Page
(Fixed Size)
Register Stack
(Fixed Size)
Program Heap
0x6000 0000 0000 0000
Executable Data
and BSS
Executable Text
0x4000 0000 0000 0000
Shared Library
Text and Data
0x0000 0000 0000 1000
MMAPs and
Shared Memory
ZK-2028U-AI
5.2.4 Symbol Resolution
Tru64 UNIX and HP-UX 11i both support depth-first and breadth-first
searching for run-time resolution of symbols; Tru64 UNIX, Itanium® 32-bit,
Itanium® 64-bit, and the PA-RISC 64-bit loaders use breadth-first by default.
See the dld.sl or dld.so reference pages for more information.
The PA-RISC 32-bit loader uses depth-first resolution by default; breadth-first
resolution is not available in the PA-RISC 32-bit environment. Applications
built with the +compat option will use depth-first resolution on HP-UX 11i.
See the dld.sl reference page for more information.
Breadth-first symbol resolution is done by starting at the root and traversing the
dependencies in order. This method ensures that all references to a symbol are
resolved to the same target.
In a simple application, using breadth-first searching, where:
•
a.out depends on libA, libB, and libc.so.
•
libA depends on libD.
•
libB depends on libE.
•
libD depends on libc.so.
•
libE depends on libc.so.
Linkers and Loaders
5–21
•
libc.so depends on nothing.
Figure 5–9 shows this dependency information graphically.
Figure 5–9: Library Dependencies
a.out
libA
libB
libD
libE
libc.so
ZK-1957U-AI
The search order used is:
a.out ⇒ libA ⇒ libB ⇒ libc.so ⇒ libD ⇒ libE
Depth-first symbol resolution starts at the referencing object, processes its
immediate dependencies, in order, and then returns to the root and searches in
each dependent library and its dependents (ignoring cycles). This method can
result in unpredictable behavior as all references may not resolve to the same
target. In fact, two searches are done, first from the referencing library and its
dependencies and then another starting with the executable and its dependencies.
Using the depth-first search algorithm and the same dependency information as in
the breadth-first example, the search order is as shown in Table 5–8.
Table 5–8: Depth-First Search Orders
5–22
Starting Point
Search Order
a.out
a.out ⇒ libA ⇒ libD ⇒ libc.so ⇒ libB ⇒ libE
libA
libA ⇒ libD ⇒ libc.so ⇒ a.out ⇒ libB ⇒ libE
libB
libB ⇒ libE ⇒ libc.so ⇒ a.out ⇒ libA ⇒ libD
libD
libD ⇒ libc.so ⇒ a.out ⇒ libA ⇒ libB ⇒ libE
libE
libE ⇒ libc.so ⇒ a.out ⇒ libA ⇒ libD ⇒ libB
Linkers and Loaders
Table 5–8: Depth-First Search Orders (cont.)
Starting Point
Search Order
libc.so
libc.so ⇒ a.out ⇒ libA ⇒ libD ⇒ libB ⇒ libE
5.2.5 Symbol Binding
Symbol binding determines when symbol resolutions are performed. There are two
types of symbol bindings: deferred and immediate. The default behavior on both
HP-UX 11i and Tru64 UNIX is to use deferred (“lazy”) binding. Deferred symbol
binding means that the loader delays computation of the address of the function
or external variable until it is needed. This allows for a faster startup time and
reduces the amount of work the loader must do by only binding symbols that are
actually used.
On Tru64 UNIX, setting the environment variable LD_BIND_NOW=1 at run time
causes the loader to use immediate binding rather than deferred. Under HP-UX
11i this must be specified as a link-time option, -B immediate; no such option
is available for Tru64 UNIX. Under immediate binding, the startup cost of an
application is increased as the loader must resolve all symbols in the image.
However, this is a one-time cost and means that run-time performance will not be
affected by the need to resolve a new function or external variable. This sort of
binding is most often used in time-critical (that is, real-time) applications.
Both immediate and deferred binding can be further modified. These subclasses
change the loader’s behavior slightly while maintaining either deferred or
immediate binding logic at the core.
Both Tru64 UNIX and HP-UX 11i support symbolic binding with -B symbolic.
Used in shared objects, symbolic binding causes symbols to be resolved locally
(internally) before attempting any other binding. Use this option carefully as
multiple shared objects may have different bindings for the same symbol.
A library or executable may contain intentionally unresolved symbols. Unresolved
symbols are a fatal error so you will not be able to start the program. One such case
is when a library (perhaps based on the operating system release) provides these
symbols. To enable such a situation, the image can be linked using nonfatal binding
(-B non_fatal) with HP-UX 11i. This is similar to the -ignore_unresolved
loader option or the -expect_unresolved linker option for Tru64 UNIX. The
symbol must be resolvable before its first reference or it is still a fatal error.
HP-UX 11i also provides a new binding option not available on Tru64 UNIX: -B
restricted. Restricted binding is similar to deferred binding, but it restricts
resolution to those libraries in memory at the time the library from which the
symbol is being referenced was loaded. For example, a new symbol resolution
occurring from a library loaded implicitly during startup would not have access to
symbols provided by libraries opened with dlopen(3).
5.2.6 Symbol Precedence
The process of resolving and binding symbols relies not only on the search order.
The precedence of the symbols is also important. Tru64 UNIX defines this
precedence (highest to lowest) as:
1.
Strong text or data
2.
Strong largest allocated common (FORTRAN common blocks, uninitialized
data, and so forth)
3.
Weak data
Linkers and Loaders
5–23
4.
Weak largest allocated common (FORTRAN common blocks, uninitialized
data, and so forth)
5.
Largest common (postlink modification or dynamically unloaded only)
6.
Weak text
If there are multiple symbols at the same precedence, the search order is used to
break the tie.
HP-UX 11i defines symbol precedence differently:
1.
Strong text or data
2.
Weak text or data
These differences may cause problems at execution time. To avoid this data and
text symbols must have unique names.
5.2.7 Environment Variables
HP-UX 11i and Tru64 UNIX provide run-time options to the loader to assist in
debugging as well as changing the run-time behavior of an application. This
section covers those environmental variables that directly affect the loader. Other
run-time related environment variables (for example, LD_LIBRARY_PATH) are
discussed in Section 7.1.
Debugging load-time bugs can be problematic. To assist in debugging, options
to the loader are provided to give feedback as the loader creates the completed
memory image. Tru64 UNIX places these arguments in _RLD_ARGS; HP-UX 11i
uses _HP_DLDOPTS. For more information on the options passed to the loader,
see Section 5.2.8.
The HP-UX 11i DLD_VERBOSE_ERR environment variable increases the number of
warnings reported by the loader. By default, only certain warnings are displayed,
and setting this variable causes all warnings to be displayed.
Immediate binding (see Section 5.2.5) on Tru64 UNIX is achieved by setting
LD_BIND_NOW. To achieve similar behavior on HP-UX 11i, use the -B immediate
linker option.
5.2.8 Loader Options
You can specify loader options by setting the appropriate environment variable
(_RLD_ARGS on Tru64 UNIX, _HP_DLDOPTS on HP-UX 11i) to a space-separated
list on both Tru64 UNIX and HP-UX 11i. There are no equivalent options between
the loaders on Tru64 UNIX and HP-UX 11i. If your application relies on any of
these options, then an alternative must be found.
Table 5–9 shows the HP-UX 11i loader options.
Table 5–9: HP-UX 11i Loader Options
5–24
Option
Description
-symtab_stat
Displays statistics on symbol table lookup performance.
-warnings
Displays additional loader warnings.
-fbverbose
Display fastbind information. See fastbind(1).
-nofastbind
Disables fastbind. See fastbind(1).
Linkers and Loaders
5.2.9 Loader APIs
Tru64 UNIX provides a series of APIs for direct loader access for legacy reasons;
there are no such mechanisms on HP-UX 11i. Table 5–10 and Table 5–11 provide a
rough mapping to assist in the transition of such APIs to more standard APIs. Not
all functionality is available, and there is no direct mapping in many cases.
Table 5–10 shows the suggested rld_new_interface( ) replacements.
Table 5–10: Tru64 UNIX rld_new_interface() Replacements
Tru64 UNIX
HP-UX 11i
_SHUT_DOWN
The exit(2) interface should be used.
_RLD_FIRST_PATHNAME,
_RLD_NEXT_PATHNAME,
_RLD_LDR_CONTEXT_INQ_MODULE,
_RLD_LDR_CONTEXT_NEXT_MODULE
The dlget( ) and dlgetname( ) functions
(see Section 13.2.2 and Section 13.2.4) can be
used to obtain similiar functionality.
_RLD_ADDR_TO_NAME,
_RLD_LDR_CONTEXT_INQ_REGION
The dlmodinfo( ) and dladdr( ) functions
(see Section 13.2.6 and Section 13.2.1) can be
used to obtain similar functionality.
_RLD_NAME_TO_ADDR
The dlmodinfo( ) function (see
Section 13.2.6) can be used to obtain
similar functionality.
_RLD_LDR_DLOPEN
The UNIX standard dlopen(3C) interface
should be used. Differences in this interface
are discussed in Section 13.2.8.
_RLD_LDR_DLSYM
The UNIX standard dlsym(3C) interface
should be used. Differences in this interface
are discussed in Section 13.2.9.
_RLD_LDR_DLERROR
The UNIX standard dlerror(3C) interface
should be used.
_RLD_LDR_DLCLOSE
The UNIX standard dlclose(3C) interface
should be used.
_RLD_LDR_SBRK
The UNIX standard sbrk(2) interface
should be used.
_RLD_LDR_BRK
The UNIX standard brk(2) interface should
be used.
_RLD_LDR_CONTEXT_ATEXIT
The UNIX standard atexit(3) interface
should be used.
Table 5–11 shows the suggested ldr_* replacements.
Table 5–11: Tru64 UNIX ldr_* Replacements
Tru64 UNIX
HP-UX 11i
ldr_next_module( ),
ldr_inq_module( )
The dlget( )and dlgetname( ) functions
(see Section 13.2.2 and Section 13.2.4) can be
used to obtain similiar functionality.
ldr_inq_region( )
The dlmodinfo( ) and dladdr( ) functions
(see Section 13.2.6 andSection 13.2.1) can be
used to obtain similar functionality.
ldr_xattach( )
Not Available
ldr_kernel_process( )
Not Available
ldr_my_process( )
The UNIX standard getpid(2) interface
should be used.
Linkers and Loaders
5–25
5.3 Linker-Related Tools
Determining the source of a problem often means getting into the internals of the
image. Tools such as those discussed in the following sections can assist you in
determining where various symbols are being resolved from, what dependencies
your application may have, and where any symbol collisions may be occurring.
5.3.1 ldd
The ldd tool displays the dependencies of a call-shared executable or shared
library. As it was only added recently to Tru64 UNIX, many people still use
the odump -Dl command to obtain this information on Tru64 UNIX. The ldd
command is the proper method of obtaining this information on HP-UX 11i. The
ldd tool takes into account information such as the current environment settings
and the image’s rpath, if any, when resolving the libraries. The odump command
does not. For example:
% ldd hello
libsin.so.1 =>
libc.so.1 =>
libdl.so.1 =>
/usr/lib/hpux32/libsin.so.1
/usr/lib/hpux32/libc.so.1
/usr/lib/hpux32/libdl.so.1
5.3.2 chatr
The chatr tool is a postlink image modification tool for HP-UX 11i. It enables you
to change information, such as pagesize, after the image has been linked. The
chatr command is also able to change dependency information, enable or disable
the use of LD_LIBRARY_PATH, and has many other useful features. With no options
specified, it provides a detailed look at the image and its current settings, including
if it is a 32- or 64-bit image. For example:
%chatr hello
hello:
32-bit ELF executable
shared library dynamic path search:
LD_LIBRARY_PATH
enabled first
SHLIB_PATH
enabled second
embedded path
enabled third \
/usr/lib/hpux32:/opt/langtools/lib/hpux32:
shared library list:
libsin.so.1
libc.so.1
shared library binding:
deferred
global hash table disabled
shared library mapped private disabled
shared vtable support disabled
segments:
index type
address
flags size
5 text
04000000
z---c
D (default)
6 data
40000000
---mD (default)
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
Detailed information about the usage of chatr and its available options can be
found in the HP-UX Linker and Libraries User’s Guide, which can be accessed
using ld +help.
5–26
Linkers and Loaders
5.3.3 elfdump
The 64-bit images on HP-UX 11i use the ELF64 standard. Some 32-bit images on
HP-UX 11i v2 also use the ELF standard. The elfdump tool is the equivalent
of odump.
Table 5–12 provides some common elfdump commands. See the elfdump(1)
reference page for more information.
Table 5–12: Common elfdump Commands
Command
Description
elfdump -a
Dumps archive headers from an archive library.
elfdump -c
Dumps the string table(s).
elfdump -L
Dumps the .dynamic section in shared libraries and
dynamically linked program files.
elfdump -t
Dumps the symbol table entries.
5.3.4 odump
The odump tool is an a.out format object information dumper. The HP-UX SOM
format and the Tru64 UNIX eCOFF format are variants of the original UNIX
a.out format. PA-RISC 32-bit applications and all images on Tru64 UNIX use
this form. In most cases on HP-UX 11i, you will need to use elfdump. The ELF
format has been adopted as the default image mode on HP-UX 11i v2 and is the
only available format (ELF64) for 64-bit images. HP-UX 11i v1 still uses the SOM
format for 32-bit images.
5.4 Linker Errors
HP-UX 11i supports two different memory models (ILP32 and LP64) and two
architectures in one operating system. As a result there are some interesting
linker problems that can result if the wrong libraries or directories are used. The
following sections discuss several linker error messages in detail.
5.4.1 Finding Which Library
Linker errors are not always verbose about which file is the source of your problem.
As a result it is sometimes difficult to determine the source of the problem, even
when it is simple to fix.
The linker provides some additional switches that can make finding the problem
file simpler. The +vtype files linker option instructs the linker to display the
files it is processing as it processes them. For example:
$cc +DD64 -Wl,+vtype,files file2.o file1.o -o test
Loading file2.o:
Loading file1.o:
ld: Mismatched Data ABI. Expected EF_IA_64_ABI64 but
found None in file file1.o
5.4.2 Mismatched Data ABI
A “Mismatched Data ABI” message indicates that one or more objects or libraries
on your link line are not the same format that you are trying to link. If you are
linking with the +DD64 option, then you have a 32-bit image in your link line; if
not, a 64-bit image was found. This can be a problem when dealing with third-party
libraries, particularly when migrating between operating systems or porting
Linkers and Loaders
5–27
between 32- and 64-bit environments. Using the chatr tool on the object files will
tell you how they were compiled. For example:
% chatr file1.o
file1.o:
64-bit ELF relocatable file
For libraries:
% chatr libfoo.so | head -n 2
libfoo.so:
32-bit ELF shared library
Mixing of data models is not supported, and these errors need to be resolved by
moving to all ILP32 or LP64 images.
5.4.3 Mismatched ABI
A “Mismatched ABI” message indicates that one or more objects or libraries on
your link line are not the same format (SOM versus ELF) that you are trying to
link. A common place this can occur is by accidentally adding a PA-RISC object file
to your link line when building an Itanium® application, or vice versa. Again, you
can use the chatr tool to identify the problem file. For example:
% chatr libfoo.sl
chatr(error): file libfoo.sl is not a valid ELF file
Alternatively, you can use the file command to identify them:
% file /usr/lib/libc.sl
/usr/lib/libc.sl: PA-RISC1.1 shared library -not stripped
5.4.4 Mismatched Machine Types
The “Mismatched machine types” message indicates a file of the wrong architecture
on the link line. This is most likely caused by the use of an incorrect directory
on a -L option. For example:
% cc +DD64 -L/lib/pa20_64 -lm foo.c
ld: Mismatched machine types. Expected EM_IA_64 but found
EM_PARISC in file /lib/pa20_64/libm.sl
Fatal error.
The error message itself identifies the problem library. In this case
/lib/pa20_64/libm.sl is the source of the problem. The correct version of the
library for the architecture will need to be located.
5.5 Recommended Linker Options
The recommended options for maximum compatibility with the Tru64 UNIX linker
are as follows:
+rpathfirst — Searches rpath before LD_LIBRARY_PATH, which makes the
behavior on HP-UX 11i v1.6 and later the same as Tru64 UNIX. This option is
not available on HP-UX 11i v1.
+noallowunsats — Displays unsatisfied symbols as an error, this option is the
default when linking executables but is disabled when linking shared libraries.
HP-UX 11i compilers also do not include the standard run-time libraries on the
shared library link line, only those libraries explicitly specified are present. This is
different than the default behavior on Tru64 UNIX.
+h libname — Sets the internal name of a shared library. Tru64 UNIX does this
by default; HP-UX 11i does not.
5–28
Linkers and Loaders
+Onoprocelim — Prevents the linker from removing “dead” routines. This is
the default on both HP-UX 11i v1 and HP-UX 11i v2; however, HP-UX 11i v1.6
enabled procedure elimination by default. Procedure elimination is enabled by the
compiler at +O4.
5.6 References
HP-UX 11i v2 dld.so(5)
HP-UX 11i v1 dld.sl(5)
HP-UX 11i v2 ld(1)
HP-UX 11i v1 ld(1)
Tru64 UNIX loader(5)
Tru64 UNIX ld(1)
HP-UX 11i v2 Release Notes:
http://docs.hp.com/en/oshpux11iv2.html#Release%20Notes
HP-UX 11i v1 Release Notes:
http://docs.hp.com/en/oshpux11i/index.html#Release%20Notes
HP-UX Linker and Libraries User’s Guide, available from ld +help and at:
http://docs.hp.com/en/hpux11iv2.html
Note that a newer version of this document may be found by using the ld +help
command.
Linkers and Loaders
5–29
6
Other Development Tools
Tools other than compilers are also required for a complete development
environment. This chapter discusses some of these other tools frequently used
by developers.
6.1 Makefiles
Tru64 UNIX provides three versions of the make command:
•
/usr/bin/make: The default. For more information, see make(1).
•
/usr/bin/posix/make: The XPG4-UNIX version. For more information,
see make(1p).
•
/usr/opt/ultrix/usr/bin/make: The System V version with some
Berkeley compatibility added. For more information, see make(1u).
Within the Tru64 UNIX Workstation Development Environment, the imake
and makedepend tools are available as a make preprocessor utility and a make
dependency tool. Unless otherwise stated, make refers to /usr/bin/make.
HP-UX 11i has only one version of the make command, /usr/ccs/bin/make,
which is symbolically linked to /usr/bin/make. The HP-UX 11i make command
conforms to the SVID2, SVID3, XPG2, XPG3, XPG4, and POSIX.2 standards. See
HP-UX 11i make(1) for more information.
The GNU implementation of make, commonly referred to as gmake, is also available
on HP-UX 11i. Environments utilizing GNU make on Tru64 UNIX are encouraged
to continue using it on HP-UX 11i. For more information, see Chapter 19.
The default Tru64 UNIX make command is available as part of the Tru64 UNIX
Migration Environment for HP-UX (Migration Environment). The Migration
Environment make command has some differences and restrictions from the
version of make that is shipped on Tru64 UNIX. For more information see:
http://www.hp.com/go/tru64appmigration
The Migration Environment also contains cc and ld jackets that map
command-line options from Tru64 UNIX syntax to HP-UX syntax where there is a
match. The cc or ld jacket translates the Tru64 UNIX compiler or link command
line to a HP-UX compiler or link command line and executes it. It can be used to
port makefiles and scripts to HP-UX by reporting translations for Tru64 UNIX cc
or ld commands.
6.1.1 Comparing the Tru64 UNIX and HP-UX 11i Makefiles
If the make -f option is not used, then make looks for makefiles in the locations
indicated in Table 6–1. Tru64 UNIX assumes RCS as the default for file source
control. HP-UX 11i assumes SCCS as the default. If the makefile is under source
control, then make will attempt to checkout a copy before building.
Other Development Tools
6–1
Table 6–1: Default Makefiles
Tru64 UNIX make
HP-UX 11i make
makefile
makefile
Makefile
Makefile
makefile,v
s.makefile
Makefile,v
SCCS/s.makefile
RCS/makefile,v
s.Makefile
RCS/Makefile,v
SCCS/s.Makefile
6.1.2 Options for the make Command
The following options from the Tru64 UNIX default make command are not
available in HP-UX 11i: -cCFmNUxy. The Tru64 UNIX option -u has different
behavior on HP-UX 11i. HP-UX 11i make defines -u to be an unconditional make
while Tru64 UNIX make will not unlink files created by RCS when passed this
option. The options, -bpefiknPqrsSt, are the same on both platforms. Table 6–2
compares the HP-UX 11i and Tru64 UNIX make options that are different or
unavailable.
Table 6–2: make Options Differences
Tru64 UNIX
HP-UX 11i
-B
Not Available
Turns off compatibility mode for old
(Version 7) makefiles.
-c
Does not try to find a corresponding
Revision Control System (RCS) file and
checks it out if the file does not exist.
Not Available
-C
Tries to find a corresponding RCS file and Not Available
checks it out if the file does not exist. This
option is on by default.
-F
Causes a fatal error to occur if the
description file is not present.
Not Available
-m
Searches for machine-specific
subdirectories automatically.
Not Available
-N
Disables all Makeconf processing.
Not Available
-u
Does not unlink files that were previously Unconditionally makes the target,
checked out by RCS. This is the opposite ignoring all timestamps.
of the -U option, which is the default.
-U
Unlinks files that were previously checked Not Available
out by RCS. This option is set as the
default. If the .PRECIOUS: pseudotarget
is defined in the dependency file, the
target files are not removed.
-w
Not Available
Suppresses warning messages.
-x
Does not execute any commands.
Not Available
-y
Checks target files for dependencies.
Not Available
6.1.3 Implementing make Rules
Tru64 UNIX has the default rule implementation in the make binary, and uses a
Makeconf file to supersede the default rules with any compilation-specific changes.
Tru64 UNIX automatically searches for a Makeconf file in the current directory.
6–2
Other Development Tools
What HP-UX 11i documentation refers to as built-in targets, Tru64 UNIX
documentation calls pseudotargets. However, the functionality is unchanged; both
platforms provide the .SUFFIX, .DEFAULT, .IGNORE, .PRECIOUS, and .SILENT
targets. The .SUFFIX target, however, does have different defaults on the two
platforms. See Table 6–3 for a comparison.
Table 6–3: Comparison of Default .SUFFIX Rules
Tru64 UNIX
HP-UX 11i
.out .o
.o
.s
.s .s~
.c
.c .c~
.a
—
.f.f~
.f .f~
.F .f90~
—
.e
—
.r
.r .r~
.y .yr .ye
.y .y~ .Y .Y~
.l
.l .l~ .L .L~
.p
.p .p~
.sh .csh
.sh .sh~
.h
.h .h~ .H .H~
—
.C .C~ .cxx .cxx~ .cpp .cpp~ .cc .cc~
The Tru64 UNIX default make command recognizes the built-in macros $@, $$@,
$?, $<, and $*. The HP-UX 11i make command recognizes all of these and adds
the POSIX $% built-in macro.
There are other differences between Tru64 UNIX and HP-UX 11i makefiles.
See the HP-UX 11i and Tru64 UNIX make command reference pages or online
documentation for more information:
http://docs.cup.hp.com/hpux/os/man_pages.html
http://www.hp.com/go/tru64docs
For more information on the make utility in the Tru64 UNIX Migration
Environment for HP-UX:
http://www.hp.com/go/tru64appmigration
6.2 Debugging Tools
Tru64 UNIX provides three debugging tools: ladebug, dbx, and kdbx.
HP provides three supported debuggers on HP-UX 11i:
1.
WDB/GDB: The HP WDB debugger is an HP-supported implementation of the
gdb debugger. It also supports source-level debugging of object files written in
HP ANSI C, HP aC++, HP Fortran, as well as gcc and g++. WDB 4.0 also
contains support for run-time memory checking and core dumping.
2.
ADB: The ADB debugger operates on assembly language programs. It allows
you to look at object files and core files that result from aborted programs, to
print output files in a variety of formats, to patch files, and to run programs
with embedded breakpoints. HP-UX 11i v2 adb incorporates the following
new features: support for Lazyfp, Dual pdir, debugging MxN threads in a
Other Development Tools
6–3
process and core, debugging INIT and MCA crash dumps, and debugging a
shared library for an attached process.
3.
Q4: q4 is a crash dump analysis and kernel-debugging tool. It is the
designated successor to QDB. Unlike QDB, which can manipulate and print
only the kernel data structures that have been hardcoded into them, q4 can
manipulate and print any kernel data structure that appears in the kernel’s
symbol debug information.
The HP Kernel Debugger (KWDB) is a source-level kernel and driver debugger for
the HP-UX operating system. KWDB is based on WDB, the user-space debugger. It
also incorporates all the features of Q4. Although KWDB is included in HP-UX 11i
v2, HP does not provide support for it.
This section discusses both the Ladebug and WDB debuggers. They both:
•
Support both kernel threads (also called native threads) and user threads
(POSIX threads).
•
Support 32-bit and 64-bit programs.
The ladebug and dxladebug debuggers are included with Tru64 UNIX. HP WDB
is included with the current HP ANSI C, HP aC++, and HP Fortran compiler
bundles. HP’s WDB ships with an extensive set of user documentation, including
quick-start guides, emacs info files, online manuals, and HTML pages. Click on
help in the GUI or look in /opt/langtools/wdb/doc/ for more information.
Online WDB documentation is located at:
http://www.hp.com/go/wdb
The following sections discuss some differences between Ladebug and WDB and
the features of WDB.
6.2.1 Locating Debug Information
The Tru64 UNIX compilers and linker insert debug information into the object
files as well as executables. The Ladebug debugger gets debug information from
the executable. On HP-UX 11i, there are two alternatives. On Itanium®-based
systems, by default, the compiler places debug information in the object files only,
which is different than the behavior on PA-RISC systems, which moves the debug
information to the executable.
To get debugger behavior most like the behavior of ladebug and dbx on Tru64
UNIX, use the +noobjdebug linker option. Using this option results in a slightly
larger executable and longer link times; however, the complete debug information
will be included. This will allow debugging of the executable on systems other
than what the program was built on.
6.2.2 Debugging Shared Libraries
Shared library debugging is disabled by default on HP-UX 11i. To debug shared
libraries you must either:
1.
Start the program from the debugger. For example:
% gdb ./a.out
2.
Or, enable shared library debugging in the executable you are running.
The debugger will not be able to place breakpoints in shared library routines
unless the process has a private copy of the shared library. If you start a program
under the debugger, then the right things happen and the process will get private
copies of shared libraries, enabling you to debug them. However, if you attach to a
6–4
Other Development Tools
running process, then you may receive a message that the debugger is unable to
write breakpoints.
On HP-UX 11i v1.6 and higher, use the chatr(1) command to enable shared library
debugging by default for a single executable. The chatr +dbg enable command
instructs the loader to map the shared libraries for debugging.
On HP-UX 11i v1, the /usr/ccs/bin/pxdb -s on <executablename> command
is used to enabled shared libary debugging.
_________________________
Note
_________________________
For PA-RISC platforms, the HP-UX 11i patch “PHSS_26340 pxdb patch”
(or any superseding patch) must be installed to obtain the required
version of pxdb. There may be multiple versions of pxdb installed on
your system. Use the one installed in /usr/ccs/bin.
6.2.3 User-Defined Alias
The ladebug alias command defines a new command to create a user-defined
alias. With WDB, you can use the define command. For example, this could be
used if you wanted to overload some common command names.
6.2.4 The Command Set
The command set used by WDB consists of the commands provided by the GNU
debugger, GDB.
The WDB debugger, a GUI on top of the industry standard GDB debugger, is the
supported debugger on HP-UX 11i. Additional information for GDB is found at
the GDB Web site:
http://sources.redhat.com/gdb/
The Guide to Using HP WDB for Ladebug Users provides a detailed discussion on
WDB commands and how they relate to Ladebug commands. This guide is included
with the Tru64 UNIX to HP-UX Software Transition Kit and is available from:
http://devrsrc1.external.hp.com/STKT/portguides.html
6.3 Program Profiling Tools
Tuning the performance of an application on a new platform is a critical piece of the
porting process. Profiling tools to determine bottlenecks in performance are a key
piece in tuning performance. This section discusses some of the tools available for
profiling your applications on HP-UX 11i. Table 6–4 provides a mapping between
the tools available on Tru64 UNIX and HP-UX 11i.
Table 6–4: Program Profiling Tools
Tru64 UNIX
HP-UX 11i
DCPI, uprofile, kprofile
HP Caliper sample_ip tool (Itanium®
processor family only)
gprof
gprof
hiprof/pixie
HP Caliper cgprof tool (Itanium® processor
family only)
prof
prof
Other Development Tools
6–5
Table 6–4: Program Profiling Tools (cont.)
Tru64 UNIX
HP-UX 11i
Spike / Compiler -feedback option
Compiler +Oprofile=use option
Third Degree
wdb memory leak detection options
6.3.1 Standard UNIX Profiling Tools
The prof and gprof tools are standard profiling tools available on most UNIX
systems. Using statistical profiling, these tools sample the CPU’s program counter
(PC) at set intervals to determine what functions and basic blocks the program
spends its execution time in.
On Tru64 UNIX systems, if the atom program analysis tools are installed, then
the version of prof installed is slightly different. The atom-based prof tool works
through program instrumentation to count the actual number of times a function or
basic block is executed rather than taking random samples of the program counter.
The prof utility on HP-UX 11i is a traditional PC-sampling implementation.
The underlying APIs in the statistical versions of prof and gprof used are the
profil( ) and monitor( ) functions in libc. If you have self-developed profiling
tools that use these APIs, they are available on HP-UX 11i with slight changes to
the argument types passed to the functions. However, the basic functionality is the
same. See the reference pages for both Tru64 UNIX and HP-UX 11i for details of
the argument type differences.
6.3.2 System Timers
The UNIX standard timer functions, timer_create(3), timer_settime(3),
timer_gettime(3), and timer_delete(3), are available on both Tru64 UNIX
and HP-UX 11i.
The timer_create( ) function allows you to create a per-process timer using
a specified system clock. The timer is acquired in a disabled state. The timer
is set using the timer_settime( ) function and may be sampled by using a
timer_gettime( ) function. Signals are also used to manage events and for
sampling.
The timers are not inherited by a child process across a fork(2) call, and are
disarmed and deleted by a call to exec(2). The timer_delete( ) function disarms
the timer if necessary, and then deletes the timer. Tru64 UNIX and HP-UX 11i
both provide timers based on the system clock. Tru64 UNIX also provides access to
an optional high-resolution clock.
Both Tru64 UNIX and HP-UX 11i provide the clock_getres(3) function to obtain
the timer resolution. The maximum resolution on HP-UX 11i is 10 milliseconds.
HP-UX 11i also supports a lightweight, high-resolution interval timer with the
gethrtime(3C) function. This API can be used to get the interval time, expressed
in nanoseconds, between two calls to the function. The value returned is 64-bit
signed integer. Because of this, this API is only supported when the code is
compiled with the -Ae option (extended ANSI) to the C compiler.
For information on chip-level timers, see Section 11.8.
6.3.3 Prospect Performance Tool
Prospect is a performance analysis tool designed to answer the question, “What is
that machine doing?” Prospect uses Kernel Instrumentation tracing and Kernel
Timing Clocks, much like the HP Glance and MeasureWare products, to collect
6–6
Other Development Tools
data on what the system is doing during a given time interval, typically while a
specific program is running. Prospect in invoked much like the time(1) command
and data is collected while the program passed as an argument to Prospect is run.
Unlike time(1), Prospect collects data from all processes run on the system and not
just from the supplied program and its descendents.
Prospect is an unsupported tool developed by HP Labs and is provided “as is” with
no warranty expressed or implied. For more information and to download a copy of
Prospect, go to the Prospect Web site at:
http://www.hp.com/go/prospect
6.3.4 HP Caliper
HP Caliper is a new performance optimization and profiling tool for HP-UX 11i on
the Intel® Itanium® processor family. You can use HP Caliper as a:
•
Profile-based optimization tool
•
Performance analysis tool
HP Caliper performs its work through a combination of binary instrumentation
and sampling of on-chip event counters built into the Itanium® processor. If
you are familiar with profile-based optimization tools on Tru64 UNIX, such as
the compiler option -feedback, the postlink optimizer, Spike, as well as the
performance analysis tools pixie, hiprof, and DCPI, you will recognize much
of the functionality and data reported by HP Caliper.
As a profile-based optimization tool, HP Caliper will generate flow graph data
for the program that can then be passed to the C or C++ compiler through the
+Oprofile=use option. This is similar to using the pixie tool on Tru64 UNIX to
generate flow graph data to pass to the -feedback option of the compiler. The
main difference is that HP Caliper does dynamic instrumentation of the program,
only instrumenting the portions of the application that actually get executed based
on the input sources of the program. In contrast, the pixie tool preinstruments
the entire program. Dynamic instrumentation can save a lot of time in the
optimization process for very large programs by not instrumenting the parts of the
program that never get executed during a profile run.
As a performance analysis tool, HP Caliper contains a number of preconfigured tool
profiles for reporting different kinds of data. The cgprof report is very similar
to the output of hiprof or the classic gprof tool. The cgprof tool measures
call graph data by actual counts, not sampling. This behavior is identical to the
hiprof atom tool. Reports that HP Caliper can generate through sampling of
event counters includes data on cache misses, branch mispredicts, and translation
lookaside buffer misses. HP Caliper also includes a function coverage report that
tells what functions in the program were actually executed during the run.
See the HP Caliper User’s Guide for more detailed information. You can find this
on the Caliper Web page at:
http://www.hp.com/go/caliper
If you are familiar with DCPI, then see Introduction to HP Caliper for DCPI Users:
http://devrsrc1.external.hp.com/STKT/portguides.html
6.3.5 Memory Leak Detection and Debugging
Tru64 UNIX provides the Third Degree tool as an aid in debugging memory
leaks and heap corruption. The WDB debugger on HP-UX provides some similar
facilities for tracking heap usage and activity during debugging. While the wdb
Other Development Tools
6–7
options do not provide all of the same functionality as third on Tru64 UNIX, you
can use them to obtain some of the same information.
For more information on the WDB heap tracking options, see Section 14.4
(Debugging Memory Problems) of the Debugging with GDB manual. This is an
HP-specific version of the GDB manual, and the memory leak detection options
are an HP-specific extension to GDB. The guide can be found by going to the
documentation link on the WDB Web site:
http://www.hp.com/go/wdb
6.4 System Profiling Tools
Whole system profiling is just as important as application profiling. Applications
do not run in a vacuum. They are affected by every other process running on a
given system. The following sections discuss the system profiling tools. Table 6–5
shows the approximate equivalence between the Tru64 UNIX and HP-UX 11i tools.
Table 6–5: System Profiling Tools
Tru64 UNIX
HP-UX 11i
collect
HP Glance (see Section 6.4.8)
iostat
iostat
netstat
netstat
Performance Manager for Tru64 UNIXa
HP OpenView Performance Manager
ps
ps
sar
sar
top
top
vmstat
vmstat
a Performance Manager has been retired in Tru64 UNIX Version 5.1B. Use the GUI of the collect utility instead.
6.4.1 top
The top utility displays the top processes by CPU utilization. It takes a sample
periodically, with a default of five seconds, and refreshes the screen. Its advantage
is that it takes up very few system resources and may be used to look at overall
system performance.
The top command on HP-UX 11i has been enhanced to support processor sets.
Table 6–6 compares the Tru64 UNIX options with the HP-UX 11i options. The
-qustime options are the same.
Table 6–6: Comparison of top Options
6–8
Option
Tru64 UNIX
HP-UX 11i
-b
Uses batch mode.
Not Available
-dcount
Shows only count displays.
Shows only count displays.
-f filename
Not Available
Output is redirected to
filename.
-h
Not Available
Hides the individual CPU
state information.
-I
Does not display idle
processes.
Not Available
-i
Uses interactive mode.
Not Available
-ofield
Sorts the process display area Not Available
on the specified field.
Other Development Tools
Table 6–6: Comparison of top Options (cont.)
Option
Tru64 UNIX
HP-UX 11i
-n
Uses noninteractive mode.
Not Available
-n number
Not Available
Shows only number processes
per screen.
-P
Not Available
Adds column PSET before
column CPU for individual
CPU (processor set)
information.
-p pset_id
Not Available
Shows load averages and
process state breakdown for
system and processor set
pset_id.
-S
Shows system processes in
the display.
Not Available
-Uusername
Shows only those processes
owned by username.
Not Available
-v
Writes version number
information to stderr then
exits immediately.
Not Available
6.4.2 vmstat
The vmstat utility provides a snapshot of the state of physical and virtual memory
on the system. The vmstat command may also be set to sample and report at a
specificed interval. The options available on Tru64 UNIX and HP-UX 11i differ
considerably. Table 6–7 lists these options.
Table 6–7: Comparison of vmstat Options
Option
Tru64 UNIX
HP-UX 11i
-i
vmstat report.
Not Available
-d
Not Available
Disk transfers.
-D
Debugging.
kmem_debug must be set.
-f
Number of forks since system Not Available
startup.
-M
Memory usage by bucket.
Not Available
-n
Not Available
Produces listing for 80
columns.
-p
Diplays statistics for VM and Not Available
UBC for all RADs.
-P
Displays accumulated
statistics about physical
memory.
Not Available
-r
Displays virtual memory
statistics for the specified
Resource Affinity Domain
(RAD) only.
Not Available
-R
Displays virtual memory
statistics for all RADs.
Not Available
-s
Displays accumulated
statistics and page size.
Not Available
-w
Appends iowait.
Not Available
Other Development Tools
6–9
6.4.3 iostat
The iostat utility interactively reports I/O statistics for disk or terminal devices.
Some of the information included is the transfer rate in KB/sec, number of seeks
per second, and average seek time in milliseconds. Table 6–8 shows the differences
between iostat on Tru64 UNIX and HP-UX 11i.
Table 6–8: Comparison of iostat Options
Option
Tru64 UNIX
HP-UX 11i
None
Displays information for
terminal, disk, and floppy.
Displays information for
disks only.
-t
Not Available
Displays information about
terminal and CPU.
6.4.4 ps
The ps command is a standard UNIX command that reports the status of processes.
Tru64 UNIX supports both the BSD and System V version of the ps command. The
BSD version is used when invoked without any options or with options not prefixed
with a dash(-). The HP-UX 11i version is System V based, and options must be
prefixed with a dash. The HP-UX 11i implementation of ps will silently ignore
additional arguments that are not prefixed. For example:
% ps aux
PID TTY
24610 pts/0
24485 pts/0
TIME COMMAND
0:00 ps
0:00 ksh
This command generates the same output as:
% ps
PID TTY
24610 pts/0
24485 pts/0
TIME COMMAND
0:00 ps
0:00 ksh
HP-UX 11i supports two additional options to the ps command: the -z and -Z
options, which support processor set functionality. Table 6–9 shows the differences
between the two implementations.
Table 6–9: Some Common ps Examples
Tru64 UNIX
HP-UX 11i
Description
ps ax
Not Available
Generates a full list of all
processes (BSD).
ps -ef
ps -ef
Generates a full list of all
processes (System V).
ps aux
Not Available
Generates a full long list of
all processes (BSD).
ps -elf
ps -elf
Generates a full long list of
all processes (System V).
6.4.5 sar
The system activity reporting tool, sar, samples the system and provides CPU or
buffer activity. Table 6–10 compares the Tru64 UNIX options with the HP-UX 11i
options.The options -Aabcdefimoqsuvy are identical on both systems.
HP-UX 11i provides sar with the base system.
6–10
Other Development Tools
Table 6–10: Comparison of sar Options
Option
Tru64 UNIX
HP-UX 11i
-g
Reports paging activities.
Not Available
-k
Reports kernel memory
allocation (KMA) activities.
Not Available
-M
Not Available
Per-CPU utilization as well
as average.
-P
Not Available
Reports processor set (pset)
information.
-P processorid
Reports activity for specified Not Available
processor.
-p
Reports paging activities.
Not Available
-p pset
Not Available
Reports the specified
processor set (pset)
information.
-r
Reports unused memory
pages and disk blocks.
Not Available
-S time
Not Available
Reports the number of
System V select(2) calls
per second.
-w
Not Available
Reports system swapping
and switching activity.
6.4.6 netstat
The netstat command is a standard UNIX networking utility that is used to
display network status. Network traffic data is optionally updated at each interval.
Table 6–11 shows the differences between netstat on Tru64 UNIX and HP-UX
11i. The options -afinprs are identical on both platforms.
Table 6–11: Comparison of netstat Options
Option
Tru64 UNIX
HP-UX 11i
interval
The interval argument
specifies, in seconds, the
interval for updating and
displaying information.
When the interval argument
is specified, netstat displays
a running count of statistics
related to network interfaces.
-A
Displays either the address Not Available
of any protocol control blocks
associated with sockets or
the addresses of routing table
entries with bitmasks.
-d
Displays the number of
dropped packets.
Not Available
-g
Displays statistics since the
system was last booted.
Shows multicast information
for network interfaces.
-H
Displays the current ARP
table.
Not Available
-I interface
Displays information about
the specified interface.
Same as Tru64 UNIX.
-I interface -c
Displays the current access Not Available
filter for the specified network
interface.
Other Development Tools
6–11
Table 6–11: Comparison of netstat Options (cont.)
Option
Tru64 UNIX
HP-UX 11i
-I interface -s
Displays the DNA Data Link Not Available
Layer counters (64-bit values)
for the specified network
interface and the adapter’s
status and characteristics.
-M
Displays Internet
Protocol multicast routing
information.
Shows the multicast routing
tables.
-m
Displays information about
memory allocated to data
structures associated with
network operations.
Not Available
-o
Displays the DNA Data Link Not Available
Layer counters (old 32-bit
values) for the specified
network interface and
the adapter’s status and
characteristics.
-R
Displays the host’s routing
tables on each Resource
Affinity Domain (RAD).
Not Available
-t
Displays timer information.
Not Available
-u
Displays information about
domain sockets.
Not Available
-z
Not Available
Sets the network interface
counters or protocol statistics
counters to 0.
6.4.7 lsof
The lsof utility displays open files. It may display all open files on a system or
may be restricted to a subset, such as NFS or sockets.
The lsof utility is a freeware utility. See Chapter 19 for the best location to
download the utility from.
6.4.8 HP Glance
HP Glance is a tool designed for performance analysis and diagnosis. While
glance is available on other platforms, it has been significantly enhanced on
HP-UX 11i. HP Glance is a layered product included in the HP GlancePlus Pak,
which is available at extra cost.
HP Glance provides a more complete and sophisticated set of data than does sar,
vmstat, iostat, and top in that it uses specialized tracing facilities included in
the HP-UX 11i kernel where the other tools obtain their data by periodic sampling.
While HP Glance is able to provide a great deal of useful information, you can sort,
arrange, and filter the data to provide only that information and instrumentation
useful to you. Additionally, the GUI version provides additional controls over fonts
and colors. HP Glance is also able to provide information in the form of graphs
and charts as well as numerical data.
The glance program also has an adviser function, which is a set of rules based
on performance metrics that you can adjust to take different actions. This can
be used in many different ways to help track different system problems on a
dynamically changing system.
6–12
Other Development Tools
HP Glance includes a Curses-based interface, the glance command and the
Motif-based gpm command. Both commands provide the same information.
HP Glance is similar to the Performance Manager for Tru64 UNIX except that HP
Glance is focused toward a single node.
Other Development Tools
6–13
7
Run-Time Environment
This chapter provides an overview of the run-time environment for HP-UX 11i.
7.1 Environment Variables
HP-UX 11i and Tru64 UNIX provide environment variables that may change the
run-time behavior of an application. This section discusses those environmental
variables.
Changing the library resolution at execution time is sometimes needed. For
example, testing an application with a new version of your library without having to
relink. The LD_LIBRARY_PATH environment variable provides this capability. Both
HP-UX 11i and Tru64 UNIX check this variable by default. Both also provide a
means of not checking it. For Tru64 UNIX, using the -no_library_replacement
link-time option restricts the search paths to rpath and the system defaults.
HP-UX 11i uses the +noenvvar link-time option to achieve the same goal.
In addition to LD_LIBRARY_PATH, HP-UX 11i also checks the SHLIB_PATH
environment variable; this test can be disabled using + noenvvar.
___________________
Common Mistake
___________________
The PA-RISC 32-bit run-time environment does not check the
LD_LIBRARY_PATH variable. Only the SHLIB_PATH is used in these
applications.
Debugging load-time bugs can be problematic. To assist in debugging, options
to the loader are provided to give feedback as the loader creates the completed
memory image. Tru64 UNIX places these arguments in _RLD_ARGS; HP-UX 11i
uses _HP_DLDOPTS. For more information on the options passed to the loader,
see Section 5.2.8.
The _RLD_ROOT environment variable is a Tru64 UNIX variable that changes
where the loader thinks root (/) is located for search purposes. There is no
equivalent for HP-UX 11i.
The _RLD_LIST environment variable on Tru64 UNIX allows the replacement or
augmentation of the defined library dependencies of an application. There are
three primary means of using _RLD_LIST:
1.
Prepending libraries to the search path; these libraries are treated as if they
were specified first on the link line, allowing you to change symbol binding.
For example:
% setenv _RLD_LIST "./lib1.so:./lib2.so:DEFAULT"
To accomplish this on HP-UX 11i, use the LD_PRELOAD variable. For example:
% setenv LD_PRELOAD "./lib1.so:./lib2.so"
% ./a.out
% unsetenv LD_PRELOAD
Note: LD_PRELOAD should always be unset immediately. Having LD_PRELOAD
set may adversely affect applications. Using the POSIX shell, this can be
ensured by using a command similar to:
$ LD_PRELOAD="./lib1.so:./lib2.so" ./a.out
Run-Time Environment
7–1
2.
Appending libraries to the search path; these libraries are treated as if they
were placed last on the link line. For example:
% setenv _RLD_LIST "DEFAULT:./lib1.so:./lib2.so"
There is no equivalent on HP-UX 11i.
3.
Replacing the library dependency list. For example:
% setenv _RLD_LIST "./lib1.so:./lib2.so"
There is no equivalent on HP-UX 11i.
Both _RLD_LIST and LD_PRELOAD are ignored for setuid/setgid applications.
LD_PRELOAD is not affected by +noenvvar.
The rpath of an application can also be affected by the linker. HP-UX 11i provides
the LPATH environment variable, which allows you to completely override the
default search path of the linker. The value of the variable is used to set the
application’s rpath at link time. See Section 5.1.3 for more information.
7.2 Process Limits
While both HP-UX 11i and Tru64 UNIX share many of the concepts of per-process
limits, the default values for these limits are very different. Per-process limits,
such as the maximum size of the data segment or stack segment of a program,
are controlled by tunable variables in the kernel. Commands such as the limit
command in the C shell, or the ulimit command in other shells, are typically
how these limits are set. The kernel controls the maximum allowable values for
these limits.
Both systems have the concepts of hard and soft limits for the stack and data
segment sizes. However, on HP-UX 11i, the values for both the hard and soft limits
are set to the same initial values. Your shell may impose lower values for the
soft limits; there are no kernel parameters for the soft limits. Tru64 UNIX sets
different default values for these limits. You may increase or decrease the value of
the soft limits such that the maximum value can be no greater than the hard limit.
Both systems control these resource limits through tunable kernel variables. Tru64
UNIX contains distinct variables to control the soft and hard limits for process data
segment size and process stack segment size. HP-UX 11i only contains variables
for the hard limits. However, HP-UX 11i contains two versions of these hard limit
variables: one for 32-bit programs and one for 64-bit programs.
Appendix F contains additional details on tuning HP-UX 11i.
Table 7–1 and Table 7–2 list the default values for the resource limits controlled
by the ulimit command (and the setrlimit( ) function) on both Tru64 UNIX
and HP-UX 11i. Note that the default value for the number of file descriptors on
HP-UX 11i is dependent upon the amount of memory configured on the system.
Table 7–1: HP-UX 11i Default Process Resource Limits
7–2
HP-UX 11i 32-bit
Applications
HP-UX 11i 64-bit
Applications
cputime
unlimited
unlimited
filesize
unlimited
unlimited
datasize
1 GB
4 GB
stacksize
8 MB
256 MB
coredumpsize
unlimited
unlimited
Run-Time Environment
Table 7–1: HP-UX 11i Default Process Resource Limits (cont.)
HP-UX 11i 32-bit
Applications
HP-UX 11i 64-bit
Applications
descriptors
512 (< 1 GB) or
2048 (>= 1 GB)a
512 (< 1 GB) or
2048 (>= 1 GB)a
memoryuse
unlimited
unlimited
a The default value depends upon the amount of memory configured on the system (< 1 GB or >= 1 GB)
Table 7–2: Tru64 UNIX Default Process Resource Limits
Soft Limit
Hard Limit
cputime
unlimited
unlimited
filesize
unlimited
unlimited
datasize
128 MB
1 GB
stacksize
8 MB
32 MB
coredumpsize
unlimited
unlimited
memoryuse
unlimited
unlimited
descriptors
4096
4096
addressspace
4 GB
4 GB
7.3 Run-Time Limits
Run-time limits affect a program’s run-time capabilities, but are not controlled
on a per-process basis. These limits, such as the number of threads per process,
are kernel tunable parameters. Table 7–3 describes and lists some of the more
important limits that affect a process for both platforms. Note that the default
value for some of the limits on HP-UX 11i is dependent upon the amount of memory
configured on the system.
Table 7–3: Default Run-Time Limits
Tru64 UNIX
HP-UX 11i
Description
Name
Default Name
Default
open_max_soft
4096
maxfiles
512 (< 1 GB) or
2048 (>= 1 GB)a
Soft file limit per process
open_max_hard
4096
maxfiles_lim
4096b
Hard file limit per process
max_threads_per_user
1024
Not Available
Maximum number of threads
per user
max_thread_proc 256b
Maximum number of threads
allowed in each process
Not Available
maxuprc
256b
Maximum number of user
processes
Not Available
nfile
16384 (< 1 GB) or
65536 (>= 1 GB)a
Maximum number of open files
system wide
Not Available
nflocks
1200 (< 1 GB) or
4096 (>= 1 GB)a
Maximum number of file locks
system wide
max_proc_per_user
256
a The default value depends upon the amount of memory configured on the system (< 1 GB or >= 1 GB)
b Dynamically tunable.
Additional frequently used kernel parameters are discussed in Appendix F.
Run-Time Environment
7–3
7.4 Permissions and umask
Applications that create files can be affected by the system defaults for directory
permissions and the umask(1) settings. This section discusses some of the more
commonly used settings.
Tru64 UNIX sets a systemwide default umask of 022 in /etc/profile. By
default, HP-UX 11i does not set a systemwide umask; a default of 000 is used. This
difference may or may not affect your application. The creation of configuration,
log, and other files should be verified for expected permissions. Applications should
utilize the umask(2) system call to ensure that the current umask setting is set
as expected for maximum portablity.
The implementation of chown(1) on Tru64 UNIX and HP-UX 11i differs. Tru64
UNIX follows the BSD standard and does not allow users to change the ownership
of a file. The chown(1) command on HP-UX 11i follows the System V standard and
allows a non-root user to change ownership of a file. The setuid and setgid bits
are reset to prevent a user from compromising system security. Note that the BSD
behavior may be implemented on HP-UX 11i by disabling the CHOWN privilege
(see setprivgrp(1M)).
The default system permissions on certain directories may also affect your
application’s installer or other temporary files. The default permissions on Tru64
UNIX for /tmp/ are 1777 (drwxrwxrwt). On HP-UX 11i releases prior to HP-UX
11i v1.6 this was not the case. Beginning with HP-UX 11i v1.6 the permissions on
/tmp/ are the same as on Tru64 UNIX. Similarly, HP-UX 11i v1.6 has also changed
the default permissions and ownership on /usr/local/. The new settings are
555 (dr-xr-xr-x) with an ownership of bin:bin. This setting differs from Tru64
UNIX, which uses 755 (drwxr-xr-x), root:system for /usr/local/.
7.5 Users and Groups
The nobody (65534) user account and nobody (65534) user group are frequently
used to run daemons and protect associated files on Tru64 UNIX. On HP-UX 11i
the accounts are nobody(-2) and nogroup(-2).
The HP-UX 11i environment does not allow users to login or set user, su(1), to the
nobody account. Further, files cannot be assigned (chown(1)), to either the nobody
or nogroup IDs. Installation tools should create a unique user and group to control
ownership and access to the installed files.
Use the useradd(1M), groupadd(1M), and passwd(1), command-line utilities to
easily create accounts. Note that the system default location for home directories
on HP-UX 11i is /home. The system default shell used when creating users is
/sbin/sh not /bin/sh as on Tru64 UNIX. This shell is more restrictive than the
POSIX shell (/bin/sh). Example 7–1 shows how to use these commands to create
a new group and user without login privileges.
Example 7–1: Creating a Locked Account
#!/bin/sh
#
# Usage: create_account <user> <group>
#
groupadd $2
if [ $? != 0 -a $? != 9 ] ; then
# 0 = success, 9 = group already exists
echo "Error creating group"
exit -1
fi
useradd -s /bin/sh -g $2 $1
if [ $? != 0 -a $? != 9 ] ; then
7–4
Run-Time Environment
Example 7–1: Creating a Locked Account (cont.)
# 0 = success, 9 = user already exists
echo "Error creating user"
exit -1
fi
passwd -l $1
This will create a user account with a shell of /bin/sh, a home directory of
/home/<user> and a primary group of <group>. The account is also locked so
no direct access is possible. This account can only be accessed by root using the
su(1) command. The groupadd and useradd commands return nonzero on error
and should be tested.
7.6 Signals and Exceptions
The following sections discuss the differences in signals and exceptions between
Tru64 UNIX and HP-UX 11i.
7.6.1 Signals
The implementation of the signal(2) system call on Tru64 UNIX and HP-UX 11i
differs in that Tru64 UNIX follows the BSD standard and HP-UX 11i follows the
System V standard. More specifically, upon delivery of a signal to a signal handler
on HP-UX 11i the signal is reset to SIG_DFL; on Tru64 UNIX the handler specified
in the signal(2) system call remains in effect.
Developers are encouraged to convert to sigaction( ) whenever possible. Both
systems fully support sigaction(2) as defined in the UNIX 95 standard. The
used of sigaction( ) provides a more comprehensive and reliable mechanism for
controlling signals. Additionally, the signal handling behavior is identical between
the systems.
The sigaction(2) system call on Tru64 UNIX does contain some functionality for
backward compatibility. On Tru64 UNIX, if the SA_SIGINFO bit is clear, then
the second argument to the signal is an integer value providing additional error
information for exception signals. This information may be used to determine
what type of exception occurred.
While this functionality is not part of the UNIX 95 standard, similar behavior is
provided on HP-UX 11i. The HP-UX 11i implementations use different values
for the additional data. Applications relying on this functionality will need to be
changed.
7.6.2 Structured Exceptions
Exception processing differs from signal handling in that control is transferred
from a point in the execution of a program to an exception handler. Unlike signals,
the exception handler is located inline at a location beyond the point of the
exception; a signal handler is invoked as a function out of context.
Tru64 UNIX provides an extension to the C standard for structured exception
handling. This functionality is not available on HP-UX 11i. Both HP aC++ and
Compaq C++ provide try-block exception handling as defined by the C++ standard.
7.6.3 Alignment Faults
The Alpha, PA-RISC, and Itanium® processors require that data be aligned on its
natural boundary. That is, a 32-bit integer must be aligned on a 32-bit boundary,
Run-Time Environment
7–5
a 64-bit integer on a 64-bit boundary, and floating-point types on their natural
boundaries. If the system tries to access data that is not properly aligned, the
system will cause an exception. Example 7–2 shows an example of code which
accesses unaligned data.
Example 7–2: Unaligned Data Access
#include <stdio.h>
/* example of an unaligned access */
struct {
int a;
int b;
int c;
} ab = { 1, 2, 3};
int main()
{
long *pb; /* pointer to a long */
printf("loading unaligned object\n");
/* assign pointer to second byte of the structure */
pb = (long *)((char *)&ab + 1);
/* This will cause an alignment exception */
*pb = 0;
printf("a:%d, b:%d, c:%d\n", ab.a, ab.b, ab.c);
return 0;
}
The Tru64 UNIX run-time environment provides support for handling unaligned
data accesses. The access can be silently corrected or a message can be issued. You
can also specify that unaligned accesses generate a SIGBUS error. By default, a
fixup is performed that results in a performance hit; however, the application
does continue to run.
Tru64 UNIX provides the uac(1) command to control the behavior of unaligned
accesses. By default, they are corrected and a message is issued. The uac p reset
command will also enable reporting of unaligned accesses. Under these conditions,
the following message will be displayed when an unaligned access occurs:
Unaligned access pid=479788 <align> va=0x140000011 pc=0x120001140
ra=0x12000113c inst=0xb7e9fff1
The uac p sigbus command can also be used to cause a SIGBUS error to be
raised. This matches the behavior on HP-UX 11i. Removing alignment faults
before moving to HP-UX 11i will reduce the number of possible problems and
make the port easier.
HP-UX 11i does not perform unaligned access fixups by default. A SIGBUS
error is raised by the operating system for each unaligned access. This
allows the application to catch the signal and emulate the data access
itself or to fatally exit (the default behavior for SIGBUS). Applications can
enable default handling of alignment fixups by linking against an additional
library: libunalign on Itanium®-based systems and libhppa.a on
PA-RISC systems. Additionally they must enable the handler by calling
allow_unaligned_data_access( ). Note that for threaded applications on
Itanium®-based systems, allow_unaligned_data_access( ) must be called
within each thread in order to handle unaligned accesses generated by the thread.
On PA-RISC systems, it is sufficient to call allow_unaligned_data_access( )
just once from the main program. More information on the handling of unaligned
data is available in the HP aC++ Programmer’s Guide available at:
http://docs.hp.com/en/dev.html
7–6
Run-Time Environment
The compilers always allocate memory with the correct alignment. Memory
managers (malloc( ), mmap( ), and others) should return values aligned to at
least the largest type (int, long, double) supported on the operating system.
The most frequent cause of alignment faults is the misuse of the C cast operator,
assigning a pointer from a smaller type (char) to a larger type (int).
Tru64 UNIX compilers provide the __unaligned keyword to cause compilers
to generate code for unaligned loads and stores when using the pointer. The
generated code is significantly more expensive than aligned data access, but is
faster than generating alignment faults.
The HP ANSI C compiler on Itanium®-based systems and the HP aC++ compiler
on both platforms provide the UNALIGN pragma, which affects the next typedef
declaration. Additional declarations are not affected, only the first typedef in
global scope following the pragma is affected. Variables accessed using the defined
type are treated as unaligned data. Example 7–3 shows an example of using the
UNALIGN pragma.
Example 7–3: Unaligned Access on HP-UX 11i
#pragma UNALIGN 1
typedef int ua_int;
typedef int a_int;
// ua_int is type int with 1 byte alignment
// a_int is type int with natural alignment
While the generated code is larger and slower, it will allow you to access the data
without throwing an alignment fault.
The compilers on both platforms also provide compile time options that cause the
compiler to generate longer code sequences to avoid hardware alignment faults.
For the C and C++ compilers on HP-UX 11i, the +unum option (where num = 1,
2, or 4) tells the compiler that code that accesses multibyte data through pointers
could be unaligned. Note that usage of the UNALIGN pragma will generate more
efficient code since the compiler will generate the longer code sequences only where
needed. Using the +unum option can significantly impact the performance of
your application.
For applications that generate a large number of unaligned accesses, usage of
the compiler pragma or option to avoid unaligned accesses may yield better
performance than requiring the operating system to handle the alignment faults.
Also note that the HP-UX 11i system and runtime libraries expect all data to
be properly aligned. If the application passes unaligned data to these libraries,
then the allow_unaligned_data_access( ) function may be used to handle
the alignment faults. In all cases, modifying your application to avoid accessing
unaligned data will provide the best performance and is strongly recommended.
7.6.4 Floating-Point Exceptions
In the Itanium® architecture there is no concept of asynchronous interrupts
or a trap shadow as on early versions of the Alpha processors. The Itanium®
architecture provides precise exceptions. That is, a processor behaves as if it were
not pipelined and Itanium® processor instructions are executed one at a time.
Any interrupt raised by the execution of an instruction is handled at execution
time, in sequential instruction order. If multiple interrupts occur in one instruction
bundle (a bundle contains three instructions), then the instruction in the lowest
numbered-instruction slot will be raised. This also applies to parallel floating-point
operations. As a result, there is no need to compile with the Tru64 UNIX -ieee
option to get precise exception faults in HP-UX 11i applications.
Run-Time Environment
7–7
On Itanium® processors, interrupts are delivered in priority order, higher priority
exceptions are flagged first and results delivered according to the requirements of
that exception. Lower priority exceptions are not flagged, even if they occur. For
example, dividing an SNaN (Signaling NaN) by zero causes an invalid operation
exception due to the SNaN and not a divide-by-zero exception. The exception
disabled result is the QNaN (Quiet NaN) definite, not infinity as would be required
by a divide-by-zero exception. However, because of the frequent occurrence of
inexact exceptions, they accompany underflow or overflow exceptions.
HP-UX 11i handles the five standard IEEE floating-point exceptions:
•
Overflow
•
Underflow
•
Invalid operation
•
Division by zero
•
Inexact result
The HP-UX 11i math libraries deal with exceptions for the more complex
operations, such as the transcendental functions. These types of exceptions depend
on compiler options and are not discussed in this guide. See the HP-UX 11i
Floating-Point Guide for more information on math libraries.
___________________
Common Mistake
___________________
The default-handling mode of floating-point exceptions is different
between HP-UX 11i and Tru64 UNIX. HP-UX 11i suppresses all
exceptions by default; Tru64 UNIX does not.
The default-handling mode of floating-point exceptions is different between HP-UX
11i and Tru64 UNIX. By default, Tru64 UNIX ignores underflow and inexact
exceptions, but overflow, divide-by-zero, or invalid operations will unconditionally
generate a trap. The HP-UX 11i exception behavior is IEEE, equivalent to -ieee
on Tru64 UNIX; it ignores all exceptions. To achieve behavior like the Tru64 UNIX
default, use the +FPOVZ option. For portability, HP recommends that you use IEEE
floating-point format when possible. The following example uses Tru64 UNIX
floating-point behavior on HP-UX 11i:
% cc +DD64 +FPOVZ foo.c
As defined by the IEEE standard, traps for the five standard exceptions are disabled
by default. These traps can be enabled in HP-UX 11i by several mechanisms:
•
The +FP compiler option
•
The +fp_exception (HP Fortran) option
•
The fesettrapenable(3) function
7.6.4.1 +FP Compiler Option
The +FPflags option is available on all compilers. Table 7–4 lists the +FP options.
Table 7–4: +FP Option Arguments
7–8
Value
Behavior
V
Enables traps on invalid floating-point operations.
v
Disables traps on invalid floating-point operations.
Z
Enables traps on divide by zero.
z
Disables traps on divide by zero.
Run-Time Environment
Table 7–4: +FP Option Arguments (cont.)
Value
Behavior
O
Enables traps on floating-point overflow.
o
Disables traps on floating-point overflow.
U
Enables traps on floating-point underflow.
u
Disables traps on floating-point underflow.
I
Enables traps on floating-point operations that produce inexact results.
i
Disables traps on floating-point operations that produce inexact results.
D
Enables flush-to-zero (fast underflow) mode for denormalized values.
(Selecting this value enables flush-to-zero mode only if it is available
on the processor that is used at run time.)
d
Disables flush-to-zero (fast underflow) mode for denormalized values.
N
Enables trap on Denormal|Unnormal operand floating-point operation.
Available on Itanium® processors only.
n
Disables trap on Denormal|Unnormal operand floating-point
operation. Available on Itanium® processors only.
The flags enable (uppercase letter) or disable (lowercase letter) one of the
floating-point exceptions. This option allows you to enable an application to flush
all denormals to zero. This is a common industry standard extension to the IEEE
actions. For example, to enable flush-to-zero mode and disable all other exceptions,
the command is:
% cc +DD64 +FPvzouiD foobar.c
The default action when exceptions are enabled with this option is to dump core.
However, this action gives no further information about the exception that caused
the core dump.
The +fp_exception or +T options, discussed in the following sections, are similar
to the Tru64 UNIX C -fptm options and the f90 -check and -fpe options.
7.6.4.2 +fp_exception HP Fortran Option
The +fp_exception option in HP Fortran is used to trap four floating-point
exceptions:
•
Invalid operation
•
Division by zero
•
Underflow
•
Overflow
Few applications actually use the inexact result information because it happens
quite often and gives little information. The +fp_exception option is similar to
the +FP option, but gives more information. The +fp_exception option provides
the type of exception and the virtual address of the offending statement, and it also
aborts the application instead of causing it to dump core.
If the +fp_exception or +T options are used with the +FP option in FORTRAN
applications, the +fp_exception is always processed before the +FP option.
However, the +fp_exception does not turn off any of the exceptions enabled
by the +FP option.
As in the case of the +FP option, the +fp_exception option is similar to the
Compaq C -fptm options and the Compaq Fortran -check and -fpe options.
Run-Time Environment
7–9
7.6.4.3 fesettrapenable Function
Use the fesettrapenable(3) function to enable one or more traps from within
an application. This allows you to be selective inside the application when
dealing with exceptions. This function has the same default action as +FP, in
that the application dumps core. The similar Tru64 UNIX function for C is
ieee_set_fp_control(3) and for FORTRAN it is for_set_fpe(3).
7.6.4.4 User Handling of FP Exceptions
If the default action of either dumping core or aborting the application is not
desired, then you must provide exception-handling routines. For C, use the
standard signal-handling sigaction(3) function to install a signal handler for
floating-point exceptions. This handler must access the various floating-point
status register flags to decode the signal, since all floating-point exceptions are
signaled by the signal SIGFP.
The ON statement allows FORTRAN programs to handle floating-point exceptions.
One of the components of the ON statement is the type of exception to handle, which
reduces the complexity of the handler as individual handlers can be written for
each type of exception when compared to that required for the SIGFP signal.
7.6.4.5 Detecting Exceptions without Enabling Traps
Use the fetestexcept(3) function from within an application to determine which
of a specified subset of the floating-point exception flags are set. If an exception
occurs when the corresponding exception trap enable flag is not set (that is, the
trap will not be detected), then the system sets the corresponding exception flag.
This flag stays set until it is explicitly cleared. This allows you to periodically
check the trap enable flags to see if any floating-point exceptions have occurred in
the application and then take the appropriate actions. The corresponding Tru64
UNIX C function is ieee_get_fp_control(3). The options for this function are
also sticky, that is, they remain set until explicitly cleared.
Be careful when using this function at higher levels of optimization (level 2 and
above). Optimizations may change the order of instructions in the application. As
a result, in optimized code a function call may not occur at the location in the
application where you intended it to be located. Use the FLOAT_TRAPS_ON pragma
to suppress optimization for sections of an application. This allows the call to
fetestexcept(3) to be precisely located in the application.
For more information, see the Intel® Itanium® Architecture Software Developer’s
Manual, Volume 1, Section 5 and the HP-UX Floating-Point Guide, Sections 5 and 6.
7–10
Run-Time Environment
8
Threads
This chapter describes how to migrate multithreaded applications from Tru64
UNIX to HP-UX 11i.
HP-UX 11i on PA-RISC and the Itanium® processor family provides a POSIX
1003.1c thread library, replacing the older POSIX 1003.4a draft standard thread
library.
It is not the intention of this guide to cover applications that are based on the
Concert Multithreaded Architecture (CMA) or the older POSIX 1003.4a draft
standard thread libraries. Applications that are based on the POSIX 1003.4a draft
standard often require extensive modifications to use the POSIX 1003.1c interface.
For more information, go to:
http://devresource.hp.com/drc/STK/docs/refs/port_threads.jsp
8.1 Overview
A POSIX 1003.1c threads library consists of more than 90 defined interfaces. The
X/Open group has also added additional interfaces to the POSIX standard, which
may be included.
In addition, vendors may provide additional, nonportable interfaces to allow
developers to exploit unique features of their systems. These interfaces are not
portable and should be avoided where possible for ease of code migration.
8.2 Standard POSIX 1003.1c interfaces
The HP-UX 11i and Tru64 UNIX POSIX 1003.1c threads libraries provide all the
standard interfaces. This significantly simplifies the migration of multithreaded
applications, but there could be some minor differences in the unspecified parts of
the POSIX 1003.1c standard.
Table 8–1 shows the default values for the POSIX thread attributes object when a
thread is initially created.
Table 8–1: POSIX Thread Attribute Default Values
Attribute
Tru64 UNIX
HP-UX 11i
detachstate
PTHREAD_CREATE_JOINABLE
PTHREAD_CREATE_JOINABLE
stackaddr
NULL
NULL
inheritscheded
PTHREAD_INHERIT_SCHED
PTHREAD_INHERIT_SCHED
schedpolicy
SCHED_OTHER
SCHED_TIMESHARE
contention scope
PTHREAD_SCOPE_PROCESS
PTHREAD_SCOPE_SYSTEM a
stacksize
5 MB
64K (PA-RISC)
256 K (Itanium®-based systems)
guardsize
PAGESIZE (8 K)
PAGESIZE (4 K)
a PTHREAD_SCOPE_PROCESS was the default for HP-UX 11i v1.6 and HP-UX 11i v2 prior to the HP-UX 11i v2 September 2004
release.
The guardsize shown in Table 8–1 will be affected by the pagesize of the
hardware platform. For more information, see Chapter 11.
Threads
8–1
There are some differences in the behavior of pthread_attr_setscope() and
pthread_attr_setinheritsched() :
•
By default, a thread’s contention scope on Tru64 UNIX is inherited
from its creator thread. The contention scope of the default thread is
PTHREAD_SCOPE_PROCESS. On HP-UX 11i, the contention scope in not
inherited.
•
To explicitly specify the contention scope on Tru64 UNIX, the inheritsched
attribute must also be specified as PTHREAD_EXPLICIT_SCHED. On HP-UX
11i, this is not required.
•
On HP-UX 11i, the creation of PTHREAD_SCOPE_SYSTEM threads with the
scheduling policy of SCHED_OTHER by use of PTHREAD_EXPLICIT_SCHED is not
allowed without the RTSCHED privilege.
Therefore, when porting an application that uses PTHREAD_SCOPE_SYSTEM,
modifications are required unless a scheduling policy other than SCHED_OTHER
(the default) is specified.
Note that for the first two items listed here, the Tru64 UNIX implementation is
required by the POSIX 1003.1–2001 and SUSv3 specifications. The HP-UX 11i
implementation may change in the future to meet these specifications.
8.3 Nonportable Thread Interfaces
HP-UX 11i and Tru64 UNIX provide additional nonportable extensions to the
standard POSIX interfaces. These will always have the suffix _np (nonportable).
These need to be identified in the code migration.
It is important to understand why the nonportable Tru64 UNIX thread interfaces
were used so that they can be replaced during the port. Table 8–2 shows the
nonportable interfaces on Tru64 UNIX and the possible equivalent functions on
HP-UX 11i.
Table 8–2: Nonportable POSIX Thread Interfaces
Tru64 UNIX
HP-UX 11i
pthread_attr_getguardsize_np(3)
pthread_attr_getguardsize(3)
pthread_attr_getname_np(3)
Not Available
pthread_attr_getstackaddr_np(3)
pthread_attr_getstackaddr(3)
pthread_attr_setguardsize_np(3)
pthread_attr_setguardsize(3)
pthread_attr_setname_np(3)
Not Available
pthread_attr_setstackaddr_np(3)
pthread_attr_setstackaddr(3)
pthread_getsequence_np(3)
Not Available
pthread_yield_np (3)
sched_yield(3)
pthread_mutexattr_gettype_np(3)
pthread_mutexattr_gettype(3)
pthread_mutexattr_settype_np(3)
pthread_mutexattr_settype(3)
pthread_mutex_getname_np(3)
Not Available
pthread_mutex_setname_np(3)
Not Available
pthread_key_getname_np(3)
Not Available
pthread_key_setname_np(3)
Not Available
pthread_unlock_global_np(3)
Not Available
pthread_cond_getname_np(3)
Not Available
8–2
Threads
Table 8–2: Nonportable POSIX Thread Interfaces (cont.)
Tru64 UNIX
HP-UX 11i
pthread_cond_setname_np(3)
Not Available
pthread_cond_signal_int_np(3)
Not Available
pthread_cond_sig_preempt_int_np(3)
Not Available
pthread_lock_global_np(3)
Not Available
pthread_rwlock_getname_np(3)
Not Available
pthread_rwlock_setname_np(3)
Not Available
pthread_delay_np(3)
nanosleep(3)
pthread_getname_np(3)
Not Available
pthread_setname_np(3)
Not Available
pthread_exc_report_np(3)
Not Available
pthread_exc_matches_np(3)
Not Available
pthread_exc_get_status_np(3)
Not Available
pthread_exc_set_status_np(3)
Not Available
pthread_get_expiration_np(3)
get_expiration_time(3)
pthread_getselfseq_np(3)
Not Available
The Single UNIX Standard v2 (SUSv2) has extended the threads library to
include new APIs which were once listed as nonportable. These APIs are shown
in Table 8–3.
Table 8–3: Single UNIX Standard v2 Threads APIs
Nonportable Interface
SUSv2 Interface
pthread_attr_getguardsize_np( )
pthread_attr_getguardsize( )
pthread_attr_setguardsize_np( )
pthread_attr_setguardsize( )
pthread_attr_getstackaddr_np( )
pthread_attr_getstackaddr( )
pthread_attr_setstackaddr_np( )
pthread_attr_setstackaddr( )
pthread_mutexattr_gettype_np( )
pthread_mutexattr_gettype( )
pthread_mutexattr_settype_np( )
pthread_mutexattr_settype( )
These new SUSv2 standard functions are available on both platforms and should
be used in favor of the legacy nonportable functions.
The Tru64 UNIX Migration Environment for HP-UX facilitates the transition
of Tru64 UNIX applications to HP-UX 11i. It includes a software compatibility
layer, which provides selected Tru64 UNIX nonportable pthread API’s as shown
in Table 8–4.
Table 8–4: Nonportable POSIX Thread Interfaces Available in the Tru64 UNIX Migration
Environment for HP-UX
API
Implementation
pthread_attr_getname_np(3)
The routine on HP-UX 11i has no support for object
names and returns an empty (zero-length) string.
pthread_attr_setname_np(3)
The routine on HP-UX 11i has no support for
object names and simply returns success.
pthread_getsequence_np(3)
The routine returns a pthread_t as this represents
a thread as a small integer on HP-UX 11i.
Threads
8–3
Table 8–4: Nonportable POSIX Thread Interfaces Available in the Tru64 UNIX Migration
Environment for HP-UX (cont.)
API
Implementation
pthread_yield_np(3)
The routine calls sched_yield( ).
pthread_mutex_getname_np(3)
The routine on HP-UX 11i has no support for object
names and returns an empty (zero-length) string.
pthread_mutex_setname_np(3)
The routine on HP-UX 11i has no support for
object names and simply returns success.
pthread_key_getname_np(3)
The routine on HP-UX 11i has no support for object
names and returns an empty (zero-length) string.
pthread_key_setname_np(3)
The routine on HP-UX 11i has no support for
object names and simply returns success.
pthread_unlock_global_np(3)
The routine operates on an internal recursive mutex.
pthread_cond_getname_np(3)
The routine on HP-UX 11i has no support for object
names and returns an empty (zero-length) string.
pthread_cond_setname_np(3)
The routine on HP-UX 11i has no support for
object names and simply returns success.
pthread_lock_global_np(3)
The routine operates on an internal recursive mutex.
pthread_rwlock_getname_np(3)
The routine on HP-UX 11i has no support for object
names and returns an empty (zero-length) string.
pthread_rwlock_setname_np(3)
The routine on HP-UX 11i has no support for
object names and simply returns success.
pthread_delay_np(3)
The routine duplicates subtleties of the Tru64
UNIX implementation rather than using the simple
mechanism of calling nanosleep().
pthread_getname_np(3)
The routine on HP-UX 11i has no support for object
names and returns an empty (zero-length) string.
pthread_setname_np(3)
The routine on HP-UX 11i has no support for
object names and simply returns success.
pthread_get_expiration_np(3)
The routine adds a struct timespec to the
current time (as returned by clock_gettime( )),
and is identical to Tru64 UNIX.
pthread_getselfseq_np(3)
The routine returns a pthread_t as this represents
a thread as a small integer on HP-UX 11i.
pthread_processor_bind_np(3)
The routine translates to
pthread_use_only_cpu(3). However,
as the implementation of contention scope and
privilege restrictions on HP-UX 11i are significatly
different, it may have limited use
8.4 POSIX Thread Scheduling
An application programmer creates and modifies the application threads using
the POSIX 1003.1c interfaces. The threads library creates and schedules these
user threads onto the kernel execution context (often known as kernel threads).
How these user threads are actually mapped onto kernel threads can affect the
debugging and performance of a multithreaded application.
Tru64 UNIX and HP-UX 11i both implement POSIX 1003.1c threads. HP-UX 11i
v1.6 and later offer both the 1x1 and the MxN threading model, where multiple
user threads are bound to multiple kernel threads.
The introduction of the MxN threading model in HP-UX 11i v1.6 increases the
similarity with Tru64 UNIX, which is also based on two-level scheduling and an
8–4
Threads
MxN threading model. The MxN threading model helps support a larger number of
threads and reduces kernel resource consumption while increasing performance for
certain classes of applications.
For HP-UX 11i v1.6 and HP-UX 11i v2 on Itanium®-based systems, the
default contention scope is PTHREAD_SCOPE_PROCESS, which is the same as
the default on Tru64 UNIX. This resulted in differences for applications being
ported from PA-RISC platforms, which have a default contention scope of
PTHREAD_SCOPE_SYSTEM. The HP-UX 11i v2 September 2004 release changes the
default contention scope to PTHREAD_SCOPE_SYSTEM to improve compatibility with
applications being migrated from PA-RISC platforms. See the following note for
instructions on building and running your application on HP-UX with a contention
scope of PTHREAD_SCOPE_PROCESS. For further information on the threads
implementation on HP-UX, see the white paper, POSIX Threads on HP-UX 11i:
http://www.hp.com/products1/unix/operating/infolibrary/
index.html#white_papers
________________
Default Threading Model
________________
For the HP-UX 11i v2 September 2004 release and later, the default
contention scope is PTHREAD_SCOPE_SYSTEM. If you are using the
MxN model with the contention scope of PTHREAD_SCOPE_PROCESS
on Tru64 UNIX (the default), then you can continue to use
PTHREAD_SCOPE_PROCESS on HP-UX by doing one of the following:
•
Explicitly define the contention scope in the source code
by using pthread_attr_setscope( ) to set the scope to
PTHREAD_SCOPE_PROCESS.
•
Compile your source code using the
-DPTHREAD_DEFAULT_SCOPE_PROCESS
option.
•
Set the PTHREAD_DEFAULT_SCOPE_PROCESS environment variable
to on, ON or 1 at run time.
•
Create a libpthread properties file,
/usr/lib/libpthread.properties. Set the
default_scope_process option to 1 in this file. Set the
environment variable PTHREAD_TUNE to 1 or ON.
Note that if more than one of these settings is enabled, then the
run-time environment variable will override the properties file, and the
properties file will override the compiler option.
8.4.1 Tru64 UNIX Threading Model
Tru64 UNIX kernel threads are created as they are needed by the application. The
number of kernel threads that the threads library creates is limited by normal
Tru64 UNIX configuration limits regarding user and system thread creation.
Normally, however, the threads library creates one kernel thread for each actual
processor on the system, plus a manager thread for bookkeeping operations.
The threads library does not delete these kernel threads or let them terminate.
Kernel threads not currently needed are retained in an idle state until they are
needed again. These idled kernel threads are deleted by the kernel if they remain
idle for a long time. When the process terminates, all kernel threads in the process
are reclaimed by the kernel.
Threads
8–5
The threads library scheduler can schedule any user thread onto any kernel
thread. Therefore, a user thread can run on different kernel threads at different
times. Normally, this should pose no problem. However, the kernel thread ID as
reported by the dbx or ladebug debuggers (in native $threadlevel) can change
at any time.
Under Tru64 UNIX Version 4.0 or higher, the threads library implements a
two-level scheduling model. The threads library schedules user threads onto kernel
execution context (often known as kernel threads or virtual processes), just as
Tru64 UNIX schedules processes onto the processors of a multiprocessing machine.
A user thread is executed on a kernel thread until it blocks or exhausts its time
slice quantum. Then, the threads library schedules a new user thread to run.
While the threads library is scheduling user threads onto kernel threads, the Tru64
UNIX kernel is independently scheduling those kernel threads to run on physical
processors. The term two-level scheduling refers to this relationship.
This division allows most thread scheduling to take place completely in user mode,
without the intervention of the kernel. Since a thread context switch does not
involve any privileged information, it can be done much more efficiently in user
mode.
The key to making the two-level scheduling model work is efficient two-way
communication between the threads library and the Tru64 UNIX kernel. When a
thread blocks in the kernel, the threads library scheduler is notified so that it can
schedule another thread to take advantage of the idle kernel thread.
8.4.2 The MxN Threading Model on HP-UX
HP-UX 11i v1.6 and later implements a MxN threading model. Multiple user
threads are run on a single kernel scheduling entity called a scheduler activation
(SA) which is similar to a kernel thread. They are managed by the kernel just like
a kernel thread. Bound threads continue to be bound to a kernel thread for the life
of the user thread. There is also a global run queue that is not associated with any
virtual processors (VPs) for POSIX real-time user threads.
In the MxN threading model on HP-UX 11i, the scheduling of user threads is
done on a VP and has a kernel thread or scheduler activation associated with it.
A VP can have a run queue of unbound user threads or no run queue when it is
running a bound thread. The default number of VPs for a process is based on
the number of processors in the system.
In user space, there is a user scheduler that is responsible for scheduling user
threads on each of the VPs. There is a sleep queue for each synchronization object
or timed sleep.
The behavior of SIGSTACK, SIGALTSTACK, and SIGSPACE is undefined when
called from unbound threads. These system calls should be called from
bound threads for them to work correctly. PTHREAD_PSET_BIND_NP and
PTHREAD_LAUNCH_POLICY_NP are only valid for bound threads. For unbound
threads these calls do not impact the threads pset binding and launch policy.
8.5 Thread Synchronization Methods
The threads in a given process execute in a shared memory address space.
Thread synchronization is required to allow competing threads to have mutually
exclusive access to shared data and system resources. There are four basic types:
semaphores, mutexes, condition variables, and read/write locking. HP-UX 11i
and Tru64 UNIX provide all four mechanisms. Programs should not need to be
modified during code migration.
8–6
Threads
8.6 Porting Applications with Read-Write Locks
HP-UX 11i and Tru64 UNIX both support read-write locks as defined by the
X/Open standard. When both readers and writers are waiting for access to an
already aquired lock, both implementations give precedence to the writers when
the lock is released. Programs using read-write locks should not need to be
modified during code migration.
8.7 Compiling and Building Multithreaded Applications
Multithreaded applications must be compiled and linked against the pthread
library on Tru64 UNIX and HP-UX 11i. There are some modifications that will be
necessary to the build process when porting an application to HP-UX 11i.
8.7.1 Compiler Switches
On Tru64 UNIX, it is necessary to use the -pthread option when building a
threaded application. This defines the necessary macros and libraries at compile
and link time. For example:
cc -o myprog myprog.c -pthread
On HP-UX 11i, specify the -mt option on the command line when building a
threaded application. This option defines the necessary macros and libraries
required for a threaded program. For example:
cc +DD64 -mt -o myprog myprog.c
The HP-UX 11i C library has stubs for the pthread routines, which means that a
threaded application can be accidentally compiled and linked without the pthread
library, with no errors from the compiler or linker. The executable fails at run time
with an error from the first pthread call. Be sure to specify the pthread library (or
use the -mt option) when linking a threaded program.
The -D_THREAD_SAFE compilation switch may be used to select the thread-safe
versions of cout, cin, cerr, and clog if you are not using locks.
8.7.2 POSIX Thread Header Files
A POSIX threads library is not only made up of a collection of standard interfaces.
It also includes C language header files, which provide the programming interfaces.
Table 8–5 shows the threads header files for HP-UX 11i and Tru64 UNIX. The
application code will need to be checked to make sure it includes the correct HP-UX
11i files.
Table 8–5: POSIX Threads Header Files
Tru64 UNIX
HP-UX 11i
pthread.h
pthread.h
pthread_exception.h
Not Available
On Tru64 UNIX, it is possible to use C exception handling for cancellation or
thread exit instead of standard cleanup handlers. This is an extension of the
nonstandard Tru64 UNIX C extension discussed in Section 7.6.2. The HP-UX 11i
POSIX threads library does not explicitly support exception handling as it is not
specified in the POSIX 1003.1c standard.
8.7.3 POSIX Shared Libraries
HP-UX 11i provides a different set of shared libraries to support the multithreaded
environment. Any build files that have explicitly specified libexc or libmach
Threads
8–7
on Tru64 UNIX will need to be modified as there are no corresponding libraries
on HP-UX 11i.
A different default suffix is used to distinguish between PA-RISC and Itanium®
shared libraries. Itanium® shared libaries use a .so suffix, PA-RISC shared
libaries use .sl. Table 8–6 compares the different POSIX shared libraries.
Table 8–6: POSIX Shared Libraries
Tru64 UNIX
HP-UX 11i
Explanation
libpthreads.so
Not Available
Tru64 UNIX CMA thread
library (Draft 4 routines).
libpthread.so
libpthread.s{l|o}
POSIX 1003.1c thread library
on both Tru64 UNIX and
HP-UX 11i.
libmach.so
Not Available
Tru64 UNIX interface
definitions for the Mach
kernel. Not used by the
threads library since Tru64
UNIX Version 4.0D.
libexc.so
Not Available
Tru64 UNIX exception
support library.
libc.so
libc.s{l|o}
System run-time library.
Not Available
libgen.s{l|o}
HP-UX 11i/SCO 64-bit
common application
programming interfaces.
8.7.4 POSIX Thread-Safe Libraries
HP-UX 11i provides thread-safe libc, libpthread, and libgen libraries;
however, a number of interfaces within these thread-safe libraries cannot be used
with multiple threads.
All interfaces are thread-safe except for the following interfaces:
bgets(3)
fdetach(3)
isastream(3)
bufsplit(3)
getc_unlocked(3)
nextkey(3)
copylist(3)
fetch(3)
putc_unlocked(3)
dbmclose(3)
firstkey(3)
putchar_unlocked(3)
dbminit(3)
getchar_unlocked(3)
setmntent(3)
delete(3)
getopt(3)
store(3)
endmntent(3)
inet_ntop(3)
strord(3)
fattach(3)
inet_pton(3)
strold(3)
If an interface has an _r counterpart, then the _r interface is thread-safe.
The thread_safety(5) reference page for HP-UX 11i consolidates all thread-safe
information for system functions and APIs in libc, libgen, and libpthread,
and indicates which are cancellation points, or are not thread-safe, or cancel-safe,
or asynchronous signal-safe.
8.8 Thread Local Storage
Thread Local Storage (TLS) is data that is allocated to a specific thread for that
thread’s lifetime. TLS is not shared between threads and is treated as if each
thread has its own copy of the data. TLS is not part of the POSIX IEEE 1003.1c
8–8
Threads
standard; however, it is supported on both HP-UX 11i and Tru64 UNIX with the
help of the platform compilers.
On Tru64 UNIX, TLS variables can be declared using the following, where
__declspec(__thread) declares the xyz TLS variable:
__declspec(__thread) static int xyz;
On HP-UX, TLS variables can be declared using the following, where __thread
declares the xyz TLS variable:
__thread int xyz;
The mechanism of using dlopen( ) and shl_load( ) to load shared libaries is
discussed in Section 13.2, but be careful when using TLS within that shared
library. HP-UX 11i v1.6 introduced support in dlopen( ) and shl_load( ) for
loading shared libraries that use the dynamic TLS model. However, if static TLS
is used, an error will be generated when attempting to load a libary through
dlopen( ) and shl_load( ). For more information on dynamic loading and TLS,
see Section 13.2.10.
8.9 POSIX Thread Debugging
HP-UX 11i and Tru64 UNIX provide different debuggers to help debug
multithreaded applications. This section discusses thread-specific features in the
debuggers. For more information on debuggers, see Section 6.2.
For HP-UX 11i the recommended debugger is WDB. This debugger is based on
the HP supported implementation of the open source GDB debugger. It supports
source-level debugging of object files written in HP C, HP aC++, and HP Fortran.
WDB can set breakpoints on a per-thread basis. When a breakpoint is hit, all
threads are stopped. WDB supports setting breakpoints on a particular thread,
traversing between threads, choosing to continue to debug either parent or child
after a fork, and other thread-specific actions. WDB stops all threads if one is
stopped. Single-stepping a particular thread does not lock-step the other threads,
which may execute one or many instructions, even reaching a breakpoint or signal
that stops the program being debugged.
The WDB debugger provides the following features to help you debug multithreaded
applications:
•
Thread-specific breakpoints
•
thread apply [thread #][all] args, a command to apply to a list of
threads
•
Automatic notification of a new thread
•
thread <thread #>, a command to list existing threads
Table 8–7 highlights the most popular Ladebug commands used to debug
multithreaded applications and the corresponding WDB debugger commands.
Table 8–7: Debugger Commands
Command Action
Tru64 UNIX Ladebug
HP-UX 11i WDB
Set Breakpoint
stop [var] [threadID]
[at line] [in func] [if
expression]
break [linespec] thread
[threadno] [if expression]
Set Tracepoint
trace [var] [threadID]
[at line] [in func] [if
expression]
Not Available
Step through current thread
step, stepi, next, nexti
step, stepi, next, nexti
Threads
8–9
Table 8–7: Debugger Commands (cont.)
Command Action
Tru64 UNIX Ladebug
HP-UX 11i WDB
Resume execution
cond [signal]
Not Available
Show thread information
show thread [IDs]
info threads
List thread in a specific state
show thread [IDs] with
state == state
Not Available
List registers for a current
thread
printreg
Not Available
List mutex in a specific state
show mutex [mutex_id_list] Not Available
[with state == state]
List condition variable in a
specific state
Apply a command to a list of
thread IDs
show condition
Not Available
when [var] [threadIDs] [at
line] [if exp] [in func]
command [; ...]
thread apply [threadno]
[all] args
[condition_IDs] [with
state == state]
For more information, go to:
http://www.hp.com/go/wdb
8.10 HP Caliper Performance Analyzer
HP Caliper is a performance analysis tool for applications on Itanium®-based
systems. It can measure multithreaded applications across multiple threads,
or it can show the results for each individual thread. For more information on
Caliper, see Chapter 6.
A minor change has been made to the thread context change on HP-UX 11i
v2 to increase application performance (about 7 percent). The context of the
thread is the set of values found in the machine registers when the thread is
running, either in user space or in the kernel. At various points, this context,
together with some other information, must be copied to memory outside the
processor while the machine registers are (or may be) used for another purpose.
This does not impact the application. Aside from performance improvements,
no changes need to be made to the application code, but support engineers
should be aware of these changes when examining register states using kernel
debuggers. See the HP-UX 11i v2 release notes for more information.
8.11 Visual Threads Performance Analyzer
Visual Threads is a diagnostic tool to analyze and refine multithreaded applications
on Tru64 UNIX. It can be used to debug potential thread-related logic problems.
You can also use it to pinpoint bottlenecks and performance problems by using its
rule-based analysis and statistics capabilities.
Visual Threads is available for HP-UX 11i v1.6 and above. For more information,
go to:
http://www.hp.com/go/visualthreads
8.12 Alternative Scheduling Algorithm
On HP-UX, applications with many threads (many more threads than processors)
that frequently contend for mutexes may suffer performance degradation due to
process scheduling that can result in process (thread) priority inversion. In normal
timesharing scheduling, a process priority will become weaker the longer it runs
8–10
Threads
and stronger the longer it is blocked until eventually a running process can get
preempted.
A running thread holding a mutex can get preempted by a thread trying to obtain a
lock on the mutex, which immediately is blocked and cannot run, maintaining its
strong priority value. The thread holding the mutex still has a weak priority and
does not get enough run time to release the mutex.
HP-UX has alternate process scheduling algorithms that a process can set using
the rtsched command or the sched_setscheduler( ) API (with the required
privilege). You can use the non-aging scheduler (SCHED_NOAGE) to avoid the
priority inversion, restoring good performance. SCHED_NOAGE is a variation of
the normal timesharing scheduler in which process or thread priorities do not age
and a process is not preempted until its time slice runs out.
For example, a command could be run using the alternate SCHED_NOAGE
scheduler like this: rtsched -s SCHED_NOAGE -p 178. For more
information, see the rtsched(1) reference page. You can also do this with the
sched_setscheduler( ) API, as shown in Example 8–1.
Example 8–1: Using SCHED_NOAGE Scheduler
#include <sched.h>
struct sched_param schedParam;
int sched_stat;
schedParam.sched_priority = sched_get_priority_max(SCHED_NOAGE);
sched_stat = sched_setscheduler(0, SCHED_NOAGE, &schedParam);
To use either the rtsched command or sched_setscheduler( ) the user
must either be root or a member of a group having PRIV_RTSCHED access (see
setprivgrp(1M)).
8.13 References
•
POSIX Threads on HP-UX 11i
http://www.hp.com/products1/unix/operating/infolibrary/
index.html#white_papers
•
Programming with POSIX Threads, by David Butenhof; Addison-Wesley
Publishing Company.
•
Tru64 UNIX Guide to the POSIX Threads Library
http://www.hp.com/go/tru64docs
Threads
8–11
9
Multiprocessor Environments
This chapter covers development of applications specifically for multiprocessor
systems. The implementations of OpenMP, MPI, and other explicit multiprocessor
development interfaces are discussed. Thread-based applications are not discussed
(see Chapter 8).
9.1 OpenMP
OpenMP is an industry standard that specifies a set of directives, library routines,
and environment variables that you can use to implement shared memory
parallelism in FORTRAN and C/C++ programs. For more information on OpenMP,
visit the OpenMP Web site at:
http://www.openmp.org/
Compaq Fortran fully supports the OpenMP Version 1.1 Specification and HP
Fortran fully supports OpenMP Version 2.0. Compaq C, Compaq C++ (Version
6.5 or later), HP C for PA-RISC , and HP aC++ for PA-RISC all support OpenMP
Version 1.0. HP aC++/HP ANSI C Version A.05.38 and later support OpenMP
Version 2.0.
Tru64 UNIX compilers also support the old-style parallel-processing interface, that
is, the language features supported before the OpenMP interface was implemented.
For information on this topic, see Chapter 13 and Appendix D of the Tru64
UNIX Programmer’s Guide. If your program uses these interfaces, convert them
according to the OpenMP specification to facilitate porting to HP-UX 11i.
9.1.1 Compiler Options
By default, the compilers on both platforms ignore all OpenMP directives unless
you specify the appropriate command-line option. For Tru64 UNIX, the option is
-omp. The corresponding option for HP-UX 11i is +Oopenmp. Since multithreading
is involved, you should also specify the -mt option for HP aC++ when using
+Oopenmp.
For HP Fortran and HP C on PA-RISC platforms, the proper optimization level
must be set on the command line or the compiler will ignore some directives.
Table 9–1 lists the minimum optimization levels required for these directives.
Table 9–1: OpenMP Directives and Optimization Levels
OpenMP Directive
HP Fortran and HP C Minimum Optimization
Levels (PA-RISC only)
PARALLEL
+03
PARALLEL DO
+03
PARALLEL SECTIONS
+03
DO
+03
SECTIONS
+03
SECTION
+03
CRITICAL
+00
Multiprocessor Environments
9–1
Table 9–1: OpenMP Directives and Optimization Levels (cont.)
OpenMP Directive
HP Fortran and HP C Minimum Optimization
Levels (PA-RISC only)
ORDERED
+00
BARRIER
+00
9.1.2 Environment Variables
The OpenMP implementation on Tru64 UNIX includes several environment
variables that are used in OpenMP programming, but are not a part of the OpenMP
standard and will not be recognized by the HP-UX 11i compilers and run-time
systems. The environment variables are MP_THREAD_COUNT, MP_STACK_SIZE,
MP_SPIN_COUNT, and MP_YIELD_COUNT. You can use the OMP_NUM_THREADS
environment variable on HP-UX 11i in place of MP_THREAD_COUNT, but the other
environment variables do not have any counterparts on HP-UX 11i.
9.1.3 Tru64 UNIX Implementation-Specific Behavior
The OpenMP specification identifies several features and default values as
implementation-specific. This section lists implementation-specific details on
Tru64 UNIX. If your application relies on any of these behaviors, you need to check
whether they are implemented on HP-UX 11i.
•
Support for nested parallel regions
Whenever a nested parallel region is encountered, a team consisting of one
thread is created to execute that region.
•
Default value for OMP_SCHEDULE
The default value is dynamic (1). If an application uses the run-time schedule
but OMP_SCHEDULE is not defined, then this value is used.
•
Default value for OMP_NUM_THREADS
The default value is equal to the number of processors on the machine.
•
Default value for OMP_DYNAMIC
The default value is 0. This implementation does not support dynamic
adjustments to the thread count. Attempts to use omp_set_dynamic( ) to set
a nonzero value will have no effect on the run-time environment.
•
Default schedule
When a for or parallel for loop does not contain a schedule clause, a dynamic
schedule type is used with the chunksize set to 1.
•
flush directive
The flush directive, when encountered, will flush all variables, even if one or
more variables are specified in the directive.
9.2 MPI
The Message-Passing Interface (MPI) is an industry standard for developing
portable message-passing applications. MPI defines a library of routines through
which MPI processes communicate. The MPI standardization effort is widely
supported by computer vendors, parallel application developers, research and
scientific groups, government institutions, and other interested parties. HP is an
active participant in the MPI Forum, the group responsible for the standard. The
following sections discuss MPI on Tru64 UNIX and HP-UX 11i.
9–2
Multiprocessor Environments
9.2.1 Compaq MPI
Tru64 UNIX users can use either Compaq MPI or MPICH from Argonne National
Laboratory and Mississippi State University. Compaq MPI is functionally
compatible with MPICH Version 1.1.1. The MPI implementation that is bundled
with AlphaServer SC systems is based on MPICH 1.2.1.
Compaq MPI supports C, C++, and FORTRAN. It is a high-performance version
of MPICH that has been optimized for Alpha-based SMP systems and Memory
Channel clusters. Compaq MPI uses a lightweight message-passing scheme to
communicate over shared memory and Memory Channel to dramatically reduce
software overhead and provide low latency, high bandwidth communications.
Compaq MPI is extensively optimized to provide low latency, high bandwidth
communication between processors anywhere in a Memory Channel cluster. It
operates transparently over shared memory and Memory Channel.
For multiprocessor AlphaServer SMP systems, Compaq MPI uses shared memory
to exchange messages. No other software is required. For Memory Channel
clusters, the TruCluster Server software allows Compaq MPI to use the Memory
Channel interconnect to exchange messages.
For systems based on a standard network interconnect (Ethernet, FDDI, or ATM),
MPICH is often used. MPICH uses network connections to exchange messages.
See Section 9.4 for more information about MPICH.
9.2.2 HP MPI for HP-UX 11i
HP MPI is an implementation of the MPI standard for HP systems. It has been
developed as a high-performance, robust, high-quality native implementation of
MPI for HP servers and workstations. HP MPI is based on MPICH and LAM from
the University of Notre Dame and Ohio Supercomputer Center. It also includes
ROMIO, a portable implementation of MPI I/O developed at the Argonne National
Laboratory.
HP MPI uses operating system-specific enhancements to provide low latency and
high bandwidth point-to-point and collective communication routines. It supports
multiprotocol execution of MPI applications on clusters of shared-memory servers.
HP MPI supports 32- and 64-bit applications, single- and multi-threaded, and
provides tools to debug and instrument MPI execution.
HP MPI is fully compliant with Version 1.2 and Version 2.0 of the MPI standards.
The technical specifications for HP MPI 2.0 (which is available on both PA-RISC
and Itanium® platforms) are:
•
Compliance with MPI 1.2 and MPI 2.0
•
C, C++ (aCC), and FORTRAN language support
•
Types of applications can be SPMD and MPMD
•
Intrahost protocol is shared memory
•
Network protocol is TCP/IP
•
HMP (HyperMessaging Protocol) over Hyperfabric hardware (MPI 1.8.1 and
above)
•
Multilevel parallelism is supported through compiler directives and pthreads
•
Thread-safe
•
MPI I/O subset with support for large files ( greater than 2 GB), based on
ROMIO from Argonne National Laboratory
•
Thread-safe MPI library, with the option of having MPI applications execute
in a multithreaded manner
Multiprocessor Environments
9–3
Table 9–2 lists the directories where HP MPI files are installed on HP-UX 11i.
The files are installed in the /opt/mpi/ directory by default. The MPI_ROOT
environment variable can be set to point to an alternate location for the files.
Table 9–2: HP MPI Paths on HP-UX
Path
Contents
bin/
Command files for HP MPI utilities
doc/
Release notes (PDF and PS files)
etc/
Configuration file
help/
Source files for the example programs
include/
Common header files
include/32/
32-bit application header files
include/64/
64-bit application header files
lib/pa1.1/
MPI PA-RISC 32-bit libraries
lib/pa20_64/
MPI PA-RISC 64-bit libraries
lib/hpux32/
MPI Itanium® 32-bit libraries
lib/hpux64/
MPI Itanium® 64-bit libraries
newconfig/
Release notes (text)
share/man/man1.Z/
Reference pages for the HP MPI utilities
share/man/man3.Z/
Reference pages for HP MPI library
9.2.3 Porting Considerations
Both Compaq MPIand HP MPI for HP-UX 11i are implementations of the MPI-2
specification. Therefore, porting MPI applications from Tru64 UNIX to HP-UX
11i should be relatively straightforward. If you are porting MPICH applications
from Tru64 UNIX, the compatible version of MPICH is also available on HP-UX
11i. See the MPICH documentation for both platforms for possible implementation
differences:
http://www-unix.mcs.anl.gov/mpi/mpich/
There are some differences between Tru64 UNIX and HP-UX 11i for MPI
commands, options, arguments, and environment variables. Table 9–3 provides a
summary of the MPI commands for HP-UX 11i. See the corresponding reference
pages and the user guide for details about options, arguments, and environment
variables.
Table 9–3: HP MPI Commands for HP-UX
Category
Command
Description
Compilation
mpicc, mpiCC, mpif77, mpif90
HP MPI C, C++, and FORTRAN
compilation utilities.
Run-time
mpiclean, mpijob, mpirun,
mpiview, xmpi, mpienv,
mpidebug, mpimtsafe
HP MPI run-time utilities for running,
querying environment variables
and other information, debugging,
thread-safe, and diagnostic libraries.
For more information about compiling, running, debugging, profiling, and tuning
HP MPI applications, see the HP MPI User’s Guide:
http://docs.hp.com/hpux/dev/index.html
#Performance%20Tools%20and%20Libraries
9–4
Multiprocessor Environments
Also, note the following restriction listed in the HP MPI 2.0 for HP-UX Release
Notes:
•
Calling MPI from Fortran 90 or C++ programs:
HP MPI complies with Version 1.2 of the MPI Standard, which defines bindings
for FORTRAN 77 and C, but not Fortran 90 or C++. Some features of Fortran
90 may interact with MPI nonblocking semantics to produce unexpected
results. Consult the HP MPI User’s Guide for details. C++ applications should
be able to use the existing C binding for MPI with no problems.
9.3 Processor Sets
Processor sets are collections of processors used to provide a finer granularity for
process scheduling on multiprocessor systems. Tru64 UNIX and HP-UX 11i both
provide commands and APIs for controlling processor sets. Under HP-UX 11i
v2, processor set support is included in the base operating system. HP-UX 11i
v1 users can install processor set support from either the HP-UX Software Pack
or download it for free from:
http://software.hp.com/ER_products_list.html
Click on “hp-ux processor sets” for this kit.
The following sections discuss the differences between the implementations of
processor sets on Tru64 UNIX and HP-UX 11i.
9.3.1 Processor Set Commands
HP-UX 11i provides almost all the functionality available in the Tru64 UNIX
processor set implementation as well as some additional features. HP-UX 11i
implements the entire processor set command interface using pset_create(1).
Not all of the available options are listed here. Table 9–4 provides a mapping of
Tru64 UNIX commands to HP-UX 11i commands.
Table 9–4: Processor Set Commands
Tru64 UNIX
HP-UX 11i
Description
pset_create(1)
psrset(1) (psrset -c)
Creates a new processor set.
pset_destroy(1)
psrset(1) (psrset -d)
Destroys a processor set,
returning assigned processors
to their default sets.
pset_info(1)
psrset(1) (psrset -i)
Displays processor set
information.
pset_assign_pid(1)
psrset(1) (psrset -b)
Assigns a PID to the specified
processor set.
pset_assign_cpu(1)
psrset(1) (psrset -a)
Adds a processor to a
processor set.
runon(1)
psrset(1) (psrset -e)
Runs the specified command
on specified the processor set.
psrinfo(1)
Not Available
Displays processor
administration information.
psradm(1)
Not Available
Stops and starts processors
in a multiprocessor system.
The Tru64 UNIX runon(1) command provides support for directly assigning
processes to a single processor or a Resource Allocation Domain (RAD). This
functionality is available on HP-UX 11i with the mpsched(1) command. The
Multiprocessor Environments
9–5
mpsched(1) command lets you bind processes at startup or that are currently
running to a given CPU or locality domain.
HP-UX 11i extends the functionality of the processor sets by allowing non-root
processor sets as well as other features, such as assigning all processes owned
by a user to a processor set. Several other system-resource reporting commands
have also been updated for processor support under HP-UX 11i. These commands
include, but are not limited to, top(1), ps(1), and sar(1). See Chapter 6 and the
HP-UX 11i reference pages for more information. For more information on the
HP-UX 11i processor set command-line interface, see the psrset(1) reference page.
9.3.2 Processor Set APIs
Tru64 UNIX requires the addition of sys/types.h and sys/processor.h to
your source for access to the processor set APIs. HP-UX 11i provides the API
prototype information in sys/pset.h.
___________________
Common Mistakes
___________________
The inclusion of sys/pset.h requires that _HPUX_SOURCE be defined.
The actual functions are located in libpset on Tru64 UNIX. HP-UX 11i provides
the processor set APIs as part of libc, so no additional libraries are required at
link time. Table 9–5 provides a mapping of the processor set APIs between Tru64
UNIX and HP-UX 11i.
Table 9–5: Processor Set APIs
Tru64 UNIX
HP-UX 11i
Description
assign_pid_to_pset(3)
pset_bind(2)
Assigns a PID to a processor set.
assign_cpu_to_pset(3)
pset_assign(2)
Assigns a processor to a processor
set.
create_pset(3)
pset_create(2)
Creates a processor set.
destroy_pset(3)
pset_destroy(2)
Destroys a processor set,
returning processors to their
default processor sets.
Not Available
pset_getattr(2) and
pset_setattr(2)
Manages processor set
attributes.
Not Available
pset_ctl(2)
Queries processor sets and
system-related information.
As with the command set, HP-UX 11i provides more processor set APIs than Tru64
UNIX. You can use the pset_getattr( ) and pset_setattr( ) routines to
control non-root access to processor sets. You can collect information on processor
sets by using the pset_ctl( ) routine. For more information on the processor set
APIs, see the reference pages.
9–6
Multiprocessor Environments
9.4 References
•
Tru64 UNIX reference pages
•
HP-UX 11i reference pages
OpenMP
•
http://www.openmp.org
•
Tru64 UNIX Programmer’s Guide
•
Parallel Programming Guide for HP-UX Systems:
http://docs.hp.com/hpux/dev/
index.html#Performance%20Tools%20and%20Libraries
MPI
•
MPI Forum:
http://www.mpi-forum.org/
•
MPI: The Complete Reference
http://www.netlib.org/utk/papers/mpi-book/mpi-book.html
•
Argonne National Laboratory:
http://www-unix.mcs.anl.gov/mpi/
•
Mississippi State Engineering Research Center:
http://www.erc.msstate.edu/
•
Compaq MPI Web site:
http://www.hp.com/techservers/software/cmpi.html
•
HP MPI User’s Guide:
http://docs.hp.com/hpux/dev/
index.html#Performance%20Tools%20and%20Libraries
•
HP Message Passing Interface Library:
http://www.hp.com/go/mpi
Multiprocessor Environments
9–7
10
Clustering Considerations
This chapter discusses the high-availability cluster offerings for HP-UX 11i. The
purpose is to introduce you to what can be expected when moving from TruCluster
Server on Tru64 UNIX to HP Serviceguard on HP-UX 11i.
_________________________
Note
_________________________
HP has announced plans to integrate VERITAS Storage Foundation
Cluster File System with HP Serviceguard. VERITAS Storage
Foundation provides simultaneous access to storage from multiple
servers. If you require this level of cluster support, wait for the product
bundle that is scheduled to be available in Q3CY2005 on HP-UX 11i v2.
In the meantime, if you are planning a port to HP-UX 11i before this
functionality is available, this chapter provides details on the current
Serviceguard product offering and how it differs from TruCluster Server.
For further details, see the white paper, Transitioning Tru64 UNIX
v5 Customers to HP-UX 11i v2: Analyzing the HP-UX 11i Roadmap
Changes in Terms of File Systems, Clusters, and Infrastructure, which
is available at:
http://h30097.www3.hp.com/pdf/
v5_file_systems_and_clusters.pdf
If you are running TruCluster Available Server Version 1.6 today, then
you will be less impacted by the migration to Serviceguard since both of
these products are similar in basic functionality, although Serviceguard
provides greater disaster-tolerant features.
Both the Serviceguard and TruCluster products provide highly available clustering
solutions, share common goals, and are both easy to implement and maintain.
They are mature products that have been shipping and deployed in the market
for years. Applications on both platforms can be active/standby or active/active.
TruCluster Server implements a shared everything architecture (SSI), consisting
of a single system disk and root filesystem. Clients and system administrators
will see the cluster as one large node. Serviceguard implements a shared storage
model where only one member can access a storage device at a time. Each server
has its own system disk.
10.1 HP Serviceguard
A Serviceguard cluster is a networked grouping of servers (host systems known
as nodes) having sufficient redundancy of software and hardware that a single
point of failure (SPOF) will not significantly disrupt service. Application services
(individual HP-UX 11i processes) and all the resources needed to support the
application are grouped together in packages. In the event of a single service, node,
network, or other resource failure, Serviceguard can automatically transfer control
of the package to another node within the cluster, allowing services to remain
available with minimal interruption.
These application packages are the basic units that are managed and moved
within an enterprise cluster. Packages can be moved from node to node with simple
operator commands, allowing scheduled maintenance and workload balancing.
Clustering Considerations
10–1
HP Serviceguard combines multiple UNIX servers into an entity called an
enterprise cluster. The servers (nodes) of a cluster are connected in a loosely
coupled manner, each maintaining its own separate processor(s), memory, and
operating system. The cluster allows application services to continue if a hardware
or software failure occurs. In the event of a failure of a component, the redundant
component takes over, protecting users from software failures as well as from
SPU, disk, or LAN component failures.
Simple operator commands allow scheduled maintenance to be performed on
one node of a cluster while other nodes continue to provide support for critical
applications. When the maintenance is complete, the node rejoins the cluster
and assumes its normal workload of application packages. This same method can
also be used to perform rolling operating system and cluster software upgrades
across a cluster. Application packages provide powerful and flexible workload
balancing mechanisms after a node failure. The net effect of this is the provision of
a virtually seamless service to the users.
Serviceguard allows multiple servers to be configured in a cluster for automatic
failover. Each Serviceguard cluster has a minimum of two LAN connections
between the servers in the cluster that are typically used to carry data and
heartbeat messages between the cluster nodes. Heartbeat messages may travel
over:
•
Ethernet
•
Fast Ethernet
•
FDDI
•
token ring
•
Gigabit Ethernet
•
serial lines
The minimum supported heartbeat configuration is dual LAN connections, which
can be shared with user traffic, or a single dedicated LAN connection with an idle
standby card. You can define more LANs to carry heartbeat traffic to increase
redundancy.
Each node in the cluster has its own private disk for the operating system and its
required data. In addition to the private disk, the cluster nodes are connected to
shared-disk storage. If the shared disks are SCSI disks, there can be no more
than four nodes sharing a disk. If the shared disks are connected using Fibre
Channel, then all nodes can access the shared disks. Concurrent data access is
only supported with Serviceguard Extension for RAC configurations with SVLM or
CVM (see Section 10.1.5 for more details).
In configuring the cluster, you may choose to designate all servers in a Serviceguard
cluster as active, or choose some as active and some as standby servers. If you
designate some of the servers as standby servers, you can take advantage of
Serviceguard’s rotating standby feature. With rotating standby, when the failed
system is repaired and rejoins the cluster, it becomes the new standby system.
Automatic failback allows applications to return to the systems on which they were
originally configured. Serviceguard also allows for online configuration changes
to the cluster, such as adding nodes, application packages, or disk volumes to
the running cluster.
10.1.1 Cluster Monitoring
HP offers system- and cluster-monitoring software as part of the Mission
Critical Operating Environment bundle. HP Event Monitoring Service (EMS)
is a system-monitoring application that works with Serviceguard and provides
10–2
Clustering Considerations
real-time monitoring of system resources such as disks, applications, and available
memory, and notification of error conditions. If EMS determines that a component
has exceeded a predefined error threshold, EMS will notify Serviceguard, which
can trigger a failover if needed. HP provides application programming interfaces
(APIs) and a development kit for EMS, allowing you to write and customize your
own monitors.
10.1.2 Enterprise Cluster Master Toolkit
HP provides scripts, through its Enterprise Cluster Master Toolkit, to enable
quick integration of various applications into Serviceguard packages. When
a prepackaged script is not available for a particular application, you or HP
consultants can do the integration by using the standard Serviceguard package
control script templates. To make customization easier, HP has a library of
templates that have been developed for hundreds of applications. You only need
to purchase one toolkit per cluster, not one per node.
10.1.3 Integrated Solutions
Serviceguard integration with key server virtualization technologies including
HP Workload Manager, on-demand solutions (including Pay per Use and Instant
Capacity) and partitioning, creates a unique offering called the Virtual Server
Environment (VSE). VSE consists of dynamically sized virtual servers. Each of
these servers intelligently expands or contracts based on the service level objectives
of the applications hosted on the server. VSE manages a pool of resources and
moves resources dynamically and automatically to meet the resource needs of
the highest priority applications before fulfilling the requests of lower priority
applications.
In the management process the VSE moves resources out of underutilized virtual
servers or reroutes applications to underutilized virtual servers — the set service
levels will follow the application accordingly. This creates improved return on IT
investments, better asset utilization, operational and administrative cost savings,
improved quality of IT service, and a significant improvement in an organization’s
agility and ability to react to unforeseen business events.
10.1.4 Serviceguard Extension for SAP R/3
For SAP customers, HP has additional offerings to ensure that there is no SPOF for
enterprisewide SAP implementations. Serviceguard Extension for SAP (SGeSAP)
provides a high-availability failover environment for the SAP central instance,
application server instances, and the backend relational database management
systems (Oracle, Informix, and DB2). This product provides automated failover for
SAP mySAP components based on SAP WAS, SAP LiveCache, and SAP R/3. For
more information on Serviceguard Extension for SAP, see the documentation at:
http://docs.hp.com/hpux/ha/
10.1.5 Serviceguard Extension for RAC
Serviceguard Extension for RAC (SGeRAC) is an add-on product to Serviceguard
that provides a framework for using Oracle Parallel Server (OPS), Oracle 9i
Real Application Cluster (RAC), and Oracle 10g RAC software. It supports the
maximum number of cluster nodes supported on the target platform when running
Oracle 9i RAC or Oracle 10g RAC. SGeRAC includes:
•
Group Membership Services
•
Cluster Manager
•
Package Manager
Clustering Considerations
10–3
•
Network Manager
•
Shared Logical Volume Manager
The package manager ensures that applications and the resources on which they
are dependent fail over as a unit. Note that packages that start and halt Oracle
instances do not fail over from one node to another; they are single-node packages.
Serviceguard Extension for RAC also offers customers the flexibility to use HP
Shared LVM (SLVM) or Veritas Cluster Volume Manager (CVM). HP Shared
LVM is an enhancement to the LVM subsystem and a free component of SGeRAC
that allows concurrent access to logical volumes for up to 16 node clusters. It
defines a cluster by grouping many devices into a single volume group that is then
managed as a single entity. This simplifies the management of a large database,
and improves database performance.
Veritas CVM, an enhanced version of the Veritas volume manager (VxVM), is also
supported by Serviceguard Extension for RAC and requires the purchase of an
additional license. It allows concurrent access to the RAC data for up to 8 node
clusters. It also allows you to modify and add nodes to a cluster without shutting
the cluster down, and adds an enhanced set of volume management features. In
order to activate a disk group on more than a two-node Serviceguard Extension
for RAC cluster, the full CVM license is required. Veritas CVM only supports the
Oracle RAC cluster configuration. You should use HP Shared LVM to configure the
cluster lock disk and LVM to configure the root logical volumes.
Each system or CPU of an enterprise cluster must license one copy of Serviceguard
Extension for RAC. Oracle Real Application Cluster software is purchased
separately from Oracle Corporation. For more information and a list of new
features, see Using Serviceguard Extension for RAC and the Serviceguard
Extension for RAC Release Notes at:
http://docs.hp.com/en/ha.html
10.1.6 Serviceguard NFS Toolkit
Serviceguard NFS is a toolkit that includes configuration files and control scripts,
and allows you to use Serviceguard to set up highly available NFS servers. Also
included is a special monitor script that is used to monitor the health of NFS
services. If a service fails, the monitor will issue a restart on the local node or
trigger a failover to another cluster node. You need to purchase only one toolkit
per cluster, not one per node.
10.1.7 Serviceguard Manager
HP provides Serviceguard Manager, a Java-based GUI that allows monitoring,
control and some configuration of Serviceguard clusters from a single workstation.
Serviceguard Manager can be used from the OpenView Network Node Manager
(NNM), OpenView OVO, or a standalone workstation and supports multiple
clusters on different subnets.
The Serviceguard Manager interface is available in five languages and can display
several sessions, where each session represents a connection. Intuitive color-codes
and badges help system administrators quickly identify an issue or potential
issue within the cluster and resolve the problem, which maximizes application
availability. Serviceguard Manager is available for Windows XP Professional
Edition, Windows 2003 Server, Red Hat Linux EL 3.0, SuSE Linux Enterprise
Server version 8, and HP-UX 11i v1 and HP-UX 11i v2.
For more details, see the Serviceguard Manager Release Notes, available at:
http://docs.hp.com/en/ha.html#Serviceguard%20Manager
10–4
Clustering Considerations
10.1.8 Cluster Lock Disk and Quorum Service
Two-node clusters typically present unique problems in terms of preserving data
integrity when there is a network failure. The cluster nodes exchange heartbeat
messages over the LANs connecting them. If a message is not received from a node
that is a cluster member within a certain period of time, the cluster attempts to
reform itself. If there is a network failure, or if the network is too congested so that
heartbeats are missed, both nodes will attempt to reform the cluster. In addition, if
you have two nodes in a cluster and one failed, the cluster would be left with just
50 percent of its total processing power.
With a three-node or larger cluster, the portion of the original cluster with the most
number of nodes is allowed to reform the cluster, and the nodes in the disconnected
subnet are removed from cluster membership. In a two-node cluster, each cluster
node represents exactly half of the cluster. If both nodes were to succeed in their
attempts to reform the cluster, data corruption to the shared disks could easily
occur since both nodes could have applications running that need to access the
same data.
To prevent this, HP introduced the concept of a cluster lock as a tiebreaker. The
cluster lock is implemented by means of a lock disk, an area on a shared disk
volume. Only one node at a time is allowed to own the cluster lock. The node that
wins the cluster lock is allowed to reform the cluster with itself as the only node.
The other cluster node is not allowed to reform the cluster and, without network
communications, cannot rejoin the cluster. This is similar to the way the quorum
disk works on TruCluster Server. The cluster lock disk is supported for clusters
with up to four nodes.
Serviceguard also provides Quorum Service software as an alternative to the
cluster lock disk. The Quorum Service is a process that runs on an HP-UX 11i
or Linux host outside of the cluster(s) for which it is providing quorum services.
The Quorum Service, which provides the functions of a lock disk, may be used in
clusters with any number of nodes, and an individual quorum service may provide
tie-breaking services to as many as 50 clusters containing up to a total of 100
nodes. The Quorum Service is a separate product provided free of charge on the
Serviceguard Distributed Components CD.
The Quorum Service runs on both HP-UX and Linux and supports multiple HP-UX
and/or Linux clusters. The Quorum Service can be configured as a package in a
cluster so that the service is highly available. The package must run outside the
cluster which the Quorum Service serves.
For more details, see the Serviceguard Quorum Service Release Notes, available at:
http://docs.hp.com/en/ha.html#Quorum%20Server
10.1.9 Geographically Dispersed Cluster Solutions
Enterprise customers who require protection beyond a single data center can take
advantage of HP’s Geographically Dispersed Cluster Solutions (also referred to
as Disaster Tolerant Solutions). Serviceguard also offers this extended distance
protection by separating its data centers up to 100 km by using Dense Wavelength
Division Multiplexing (DWDM) along with MirrorDisk/UX or Veritas VxVM for
software-based data replication. This solution is referred to as Extended Campus
Cluster. Serviceguard is the foundation for two additional solutions, including
MetroCluster and Continental Clusters, which offer robustness and flexibility for
customers requiring greater performance and greater distance protection.
TruCluster Server does not currently support geographically dispersed clusters.
The maximum tested distance between nodes in a TruCluster Server Campus
Clustering Considerations
10–5
cluster is 6 km. This is due to the hardware restrictions imposed by the Memory
Channel interconnect.
10.2 Comparison of TruCluster Server to HP Serviceguard
This section provides a comparison of TruCluster Server to Serviceguard.
10.2.1 Feature Set Comparison
Table 10–1 lists a feature comparison between Serviceguard and TruCluster Server.
Table 10–1: Feature Set Comparison
Configuration
TruCluster Server
Version 5.1B
HP Serviceguard A.11.16
Maximum number of nodes supported 8
in a cluster
16
Storage configuration
Shared nothing or shared
disks
Shared disks
Clusterwide file system with a shared Yes
root
No
Clusterwide network (cluster alias)
Yes
Yesa
Clusterwide ownership of storage
devices
Yes
No
Single security domain
Yes
No
Common naming of I/O devices
Yes
No
Single-event manager and error log
Yes
Yesa
Single view of I/O resources for the
cluster
Yes
No
Users are authorized once for all
cluster nodes
Yes
Yesa
Consolidated management station
Yes
Yes
Web-based management
Yes
Yes
Add/remove nodes without bringing
down the cluster
Yes
Yes
Perform rolling upgrades of the
operating system across the cluster
(cluster remains available during
process)
Yes
Yes
Yes
Perform rolling upgrades of
applications across the cluster
(applications remain available to users
during process)
Yes
a Add-on software required
10.2.2 Cluster File System and Single-System Image
One of the main differences between the cluster functionality provided with
HP-UX 11i and Serviceguard, and the functionality provided by Tru64 UNIX and
TruCluster Server, is the cluster file system (CFS). The CFS mounts each file
system and maintains cache coherency clusterwide. This includes memory-mapped
files. Each cluster member can see and potentially access every mounted file
system providing support for AdvFS, UFS, NFS, MFS, and DVDFS.
With Serviceguard, an individual file system is mounted by one member in the
cluster only. There are no clusterwide mounts and file system support for VxFS,
10–6
Clustering Considerations
HFS, NFS, CDFS, or LOFS. NFS support for client and server access to a cluster
node can be an NFS client to another member in the same cluster. With SGeRAC,
SLVM volume groups or CVM disk groups can be activated concurrently on
multiple nodes in the cluster. However, file systems are not supported with SLVM
or CVM; only raw volumes are supported.
A CFS is the underlying architecture that allows for a single system image; that
is, all the servers in a cluster are viewed as one system, making it possible to
automatically recognize additional servers as they are added to a cluster, and
automatically balancing the load across the cluster. A single-system image exists
when the cluster contains the following three components:
•
A cluster file system, also known as a global file system.
•
A cluster alias, also known as a clusterwide network.
•
Clusterwide storage, that is, a clusterwide ownership of storage devices.
When the cluster has a single-system image, it is easier to work with the cluster
in many ways: easier for users to connect to, easier to manage, easier to change,
and easier to develop highly available applications. A cluster with a single-system
image provides many benefits:
•
With a common, clusterwide file system, especially with a shared-root system,
files such as user authorization files (UAFs) need only be created once. The
entire cluster becomes a single-security domain.
•
By providing a single-system image, the operating system and application
software need only be installed once for the entire cluster. Because the cluster
operates as a single domain, there is no need to manually configure security
privileges or other attributes that must be synchronized across all servers.
•
With a common cluster alias, the cluster appears as a single IP address on the
network, and clients do not have to connect to a specific system for services.
If the system providing a service goes down, client requests are automatically
redirected to another system in the cluster.
•
With clusterwide ownership of storage, there can be a common naming of
files and I/O devices from any cluster node, which simplifies the creation of
failover scripts. The single shared root and global name space of CFS also
enable clusterwide, transparent access to all physical storage, including SCSI,
magnetic tape, DVD, and CD-ROM.
TruCluster Server has supported a single-system image since TruCluster Server
Version 5.0. Serviceguard currently does not provide a single-system image,
although administrative commands can be easily replicated onto all the cluster
nodes using HP’s ServiceControl Manager, bundled with HP-UX 11i.
10.2.3 Cluster Interconnects
TruCluster Server and Serviceguard clusters can both be configured with industry
standard hardware, and they also offer highly optimized, high-speed cluster
interconnects. Table 10–2 compares the supported interconnects for the two
platforms.
For Oracle RAC clusters, the interconnect is known as the Cache Fusion
interconnect. On HP-UX, Oracle RAC currently supports Ethernet, Ethernet with
APA, or HyperFabric for the Cache Fusion interconnect. Infiniband support is
also planned for the near future.
Clustering Considerations
10–7
Table 10–2: Supported Cluster Interconnect Technologies
Interconnect
TruCluster Server
Tru64 UNIX Version
5.1B
HP Serviceguard
A.11.16
Ethernet
Not Available
Supported
Fast Ethernet
Supported
Supported
Gigabit Ethernet
Supported
Supported
10 Gigabit Ethernet
Not Available
Supported
FDDI
Not Available
Supported
HyperFabric2 (up to 2.4 Gb/sec)
Not Available
Supported for Oracle
RAC only
IP over Infiniband
Not Available
Supporteda
Token Ring
Not Available
Supported
Memory Channel (100 MB/sec)
Supported
Not Available
Serial lines
Not Available
Supported
a Requires HP-UX 11i v2 with patch PHSS_32740 or higher
10.2.4 High-Availability Agents
Table 10–3 lists some of the high-availability agents, or scripts, available from
vendors offered with their clustering solutions. These agents make the application
cluster-aware and generally provide graceful failover capability. Applications can
be integrated by either scripts or APIs. Failure recovery is performed by either
restarting the application on the local node or moving it to another functional node
in the cluster. The scripts can have dependencies between applications to force an
ordered startup, shutdown, or ordered relocation of applications. This functionality
is integrated into TruCluster Server with the cluster application availability (CAA)
subsystem, and by a separate scripting toolkit (Enterprise Cluster Master Toolkit)
with Serviceguard.
_________________________
Note
_________________________
The agents listed in Table 10–3 are for Serviceguard on PA-RISC but
should work on Itanium®-based servers. Most agents will eventually
become available for the Itanium® version of Serviceguard but check
with the vendor for supported versions and release dates.
Table 10–3: High-Availability Agents (Scripts) for Third-Party Applications
Available Agents
10–8
TruCluster Server
Tru64 UNIX Version
5.1B
HP Serviceguard A.11.16
Oracle 8
Yes
PA-RISC only
Oracle 9i
Yes
Yes
Oracle RAC
Yes
Yes
Informix
Yes
Yes
Sybase
Yes
Yes
IBM DB2
No
Yes
Progress
Yes
Yes
Netscape FastTrack/Enterprise
Yes
Yes
Clustering Considerations
Table 10–3: High-Availability Agents (Scripts) for Third-Party Applications (cont.)
Available Agents
TruCluster Server
Tru64 UNIX Version
5.1B
HP Serviceguard A.11.16
Netscape Directory Server
Yes
Yes
Netscape Collaboration Server
Yes
No
Netscape Mail Server
Yes
No
Apache Web Server
Yes
Yes
HP CIFS/9000 Server
No
Yes
HP Tomcat-based Servlets
Yes
Yes
Zeus Web Server
No
Noa
BEA/Tuxedo
Yes
Yes
Baan
Yes
Noa
SAP R/3
Yes
Yes
PeopleSoft
No
Noa
Candle
No
Noa
Oracle Financials, Manufacturing
Noa
Noa
Unicenter TNG
Yes
Noa
Network File System (NFS)
Yes
Yes
Domain Naming System (DNS)
Yes
Noa
SAMBA PC Service
Yes
Noa
a Although no certified agents have been produced, HP customers have written scripts for these applications working
with Serviceguard.
10.3 References
Additional information about Serviceguard and related high-availability topics
may be found on HP’s high-availability Web page:
http://www.hp.com/go/ha
Online versions of user guides and white papers are available from the HP-UX 11i
High Availability Documentation Web page at:
http://docs.hp.com/hpux/ha/
Clustering Considerations
10–9
11
Hardware Considerations
This chapter contains information about the Alpha, PA-RISC and the Itanium®
processor families. It also discusses processor-related development issues
and provides examples using both C and assembly language for typical
processor-dependent code. Most of the APIs and techniques discussed in this
chapter are highly nonportable. As a result, be careful when using these practices
as they will result in significantly more work when supporting additional platforms
or operating systems.
11.1 Itanium® Processor Family Overview
The Itanium® architecture was developed by HP and Intel® as a 64-bit
processor for engineering workstations and e-commerce servers. The Itanium®
processor family uses a new architecture called Explicitly Parallel Instruction
Computing (EPIC).
Some of the most important goals in the design of EPIC were instruction-level
parallelism, software pipelining, speculation, predication, and large register
files. These allow Itanium® processors to execute multiple instructions
simultaneously. EPIC exposes many of these parallel features to the compiler
(hence “Explicitly” in the name). This increases the complexity of the compiler,
but it allows the compiler to directly take advantage of these features.
EPIC is designed so future generations of processors can utilize different levels
of parallelism, which increases the flexibility of future designs. This allows
the machine code to express where the parallelism exists without forcing the
processor to conform to previous machine widths.
For more information on assembly programming for the Itanium® processor
family, see the Intel® Itanium® Architecture Assembly Language Reference
Guide. Available at:
http://developer.intel.com/software/products/
opensource/tools1/tol_whte2.htm
Hardware Considerations
11–1
11.2 PA-RISC Processor Family Overview
The PA-RISC architecture was developed by HP and first introduced in 1986.
It was one of the first commercially available RISC processors, including the
fixed-size, hardware-inspired instructions common to RISC designs, but also
including additional instructions for manipulating strings and other data
types used in commercial processing. This enhancement to the typical RISC
instruction set was a direct result of research by HP for a processor design
optimized over the full range of technical and commercial applications.
The PA-RISC architecture included several features to increase parallelism
and speed program execution. Instruction pipelining, delayed branching
(delay slot), instruction cache prefetch based on branch prediction, and a
Shift-and-Add instruction to speed integer multiplication are a few of the
key features in the design. These features require a complex compiler with a
detailed understanding of the architecture, but permit a tremendous reduction
in instruction path length over conventional processor designs.
The PA-RISC architecture has been through several enhancements since it
was introduced. The current revision (PA-RISC 2.0) is a 64-bit implementation
and includes instructions for multimedia processing and features to improve
cache performance. More detailed information on the PA-RISC architecture
can be found in, PA-RISC 2.0 Architecture by Gerry Kane, Prentice Hall,
ISBN 0-13-182734-0.
11.3 Defining a “word”
Data access can be accomplished using 8-, 16-, 32-, or 64-bit elements. The terms
byte and word are used to provide non-numerical terms for describing the data
sizes. Elements larger then these basics are defined in terms of either bytes
or words.
A byte is defined to be 8 bits. The size of a word has never been formally defined.
As a result there are a number of definitions used. The IA-32 processor line and
the Alpha processor define a word as 2 bytes (16 bits). Both the PA-RISC and the
Itanium® architectures define a word as 32 bits. As a result of the differences in
the definitions of word-sized elements, elements which are defined as composed
of multiple word elements are also affected. Table 11–1 provides a mapping of
common terminology for element sizes between the Alpha, Itanium®, and PA-RISC
architectures.
Table 11–1: Multi-byte Element Terminology
Bit Size
Byte Size
Alpha
Architecture
Itanium®
Architecture
PA-RISC
Architecture
8
1
byte
byte
byte
16
2
word
halfword
halfword
32
4
longword
word
word
64
8
quadword
longword
longword
128
16
octaword
quadword
quadword
11.4 Data Alignment
Data alignment is important on the Alpha, Itanium®, and PA-RISC processors.
Unaligned data access can be extremely expensive or prohibited. When permitted,
the high cost of correcting unaligned data access is because multiple memory
accesses are actually performed and the appropriate bytes are then reconstructed
to the form requested. Depending on the architecture, this operation may be
performed by the hardware but more frequently is done in software. Often this
11–2
Hardware Considerations
alignment fixup requires hundreds of cycles for each unaligned access, significantly
impacting the performance of the application.
Section 7.6.3 contains more information and examples on data alignment
management on HP-UX 11i.
11.5 Determining Processors and Configurations
There are several ways to identify the version of the processor(s) in a system. For
HP-UX 11i, the recommended way is to use sysconf(_SC_CPU_VERSION) from
within a program or getconf from the command line as shown in Example 11–1.
Example 11–1: Identifying the CPU From the Shell
% getconf _SC_CPU_VERSION
768
The values for each type of processor are listed in unistd.h; a portion of these
definitions are show in Table 11–2.
Table 11–2: _SC_CPU_VERSION Values
Processor
C define
Hex Value
Decimal
Value
Motorola MC68020
CPU_HP_MC68020
0x20C
524
Motorola MC68030
CPU_HP_MC68030
0x20D
525
Motorola MC68040
CPU_HP_MC68040
0x20E
526
HP PA-RISC 1.0
CPU_PA_RISC1_0
0x20B
523
HP PA-RISC 1.1
CPU_PA_RISC1_1
0x210
528
HP PA-RISC 1.2
CPU_PA_RISC1_2
0x211
529
HP PA-RISC 2.0
CPU_PA_RISC2_0
0x214
532
Itanium® Revision 0
CPU_IA64_ARCHREV_0
0x300
768
Example 11–2 provides a C code fragment to identify the current processor.
Example 11–2: Determining Processor Type Using C
#include <unistd.h> /* for CPU_PA_RISC definitions */
switch(sysconf(_SC_CPU_VERSION))
{
case CPU_PA_RISC1_0:
/* should not see this case much */
....
case CPU_PA_RISC1_1:
/* still popular! */
....
case CPU_PA_RISC2_0:
/* Current Machines */
....
case CPU_IA64_ARCHREV_0: /* Rev 0 of Itanium */
....
default:
....
/* Unrecognized */
}
If you just need to determine if the current processor is a PA-RISC machine,
the following code fragment will work:
#include <unistd.h>
if (CPU_IS_PA_RISC(sysconf(_SC_CPU_VERSION)))
Hardware Considerations
11–3
Sometimes additional processor information is required. One such case is in
determining if the processor is an Itanium® or an Itanium® 2 processor. The
sysconf( ) and getconf arguments to access these additional sources of
information are shown in Table 11–3.
Table 11–3: Parameters for Additional Processor Information
Argument
Behavior
_SC_CPU_CHIP_TYPE
Returns information from Itanium® processor family CPUID[3].
Figure 11–1 shows the regions defined for CPUID[3]. See
the Itanium® processor family architecture definition for the
meaning of each bit.
_SC_CPU_KEYBITS1
Returns information from Itanium® processor family CPUID[4],
and the processor extension information on PA-RISC. See the
architecture manuals for the exact meaning of each bit.
The Itanium® processor family uses a processor identification register file
(CPUID) which contains five 64-bit registers in a fixed region, registers 0 to 4,
and a variable region, register 5 and above. The variable region of the CPUID
register file is currently not implemented, but may be in future members of
the Itanium® processor family.
The name of the supplier of the CPU is stored in the 16 bytes of CPUID[0] and
CPUID[1]. They are stored so the first letter is stored in byte 0, the second
letter in byte 1, and so on. For example, for "IntelCorporation" the "I" is stored
in byte 0 and the final "n" is in byte 15.
CPUID[2] is currently not used. CPUID[3] contains 40 bits that identify the
processor, while CPUID[4] contains general application-level information
about the features supported in the processor.
The Itanium® processor family CPUID[3] register contains the processor
architecture revision that the processor implements (archrev), processor
family (family), processor model number within the processor family (model),
revision number (revision) or stepping of the processor, and the index of
the largest implemented CPUID registers (number). The number of registers
implemented is one greater than the value of number. Figure 11–1 shows the
information contained in CPUID[3].
Figure 11–1: CPUID[3] Bit Positions
63
40 39
reserved
32 31
archrev
24 23
family
16 15
model
revision
87
0
number
ZK-1958U-AI
In addition to the sysconf( ) and getconf interfaces, HP-UX 11i v2
provides the machinfo(1) command. The /usr/contrib/bin/machinfo
tool provides information, including detailed processor information, as well
as other useful machine information.
System Configurations
Another useful type of information is the number of processors in a given system.
Use the pstat_getdynamic(3) system call to obtain this information. See
Example 11–3.
11–4
Hardware Considerations
Example 11–3: Number of CPUs Using C
#include <sys/param.h>
#include <sys/pstat.h>
#include <sys/unistd.h>
int main() {
struct pst_dynamic psd;
//obtain number of cpus
if (pstat_getdynamic(&psd, sizeof(psd), (size_t)1, 0) != -1)
{
size_t nspu = psd.psd_proc_cnt;
/* Number of CPUs */
printf("Number of CPU: %d\n", nspu);
return 1;
} else {
printf("Error");
return 0;
}
}
To determine the processor clock speed, use the pstat_getprocessor(2) system
call. Example 11–4 uses sysconf( ) and pstat( ) to get several pieces of
information, including:
•
Clock ticks per second
•
Number of CPUs in the system or partition
•
Speed of each CPU
Example 11–4: Collecting System Information in C
#include
#include
#include
#include
#include
<sys/param.h>
<sys/pstat.h>
<sys/unistd.h>
<inttypes.h>
<stdio.h>
main()
{
struct pst_dynamic psd;
struct pst_processor *psp;
long ticks_per_sec;
//obtain clock ticks per second
if ( (ticks_per_sec = sysconf(_SC_CLK_TCK)) == -1)
{
perror("sysconf");
exit(-1);
}
//obtain number of spus
if (pstat_getdynamic(&psd, sizeof(psd), (size_t)1, 0) != -1)
{
size_t nspu = psd.psd_proc_cnt; /* Number of CPUs */
psp = (struct pst_processor *)malloc(nspu*sizeof(struct
pst_processor));
//for each processor, get cycles per clock tick
if (pstat_getprocessor(psp, sizeof(struct pst_processor),
nspu, 0)==nspu)
{
int i;
Hardware Considerations
11–5
Example 11–4: Collecting System Information in C (cont.)
int64_t cycles_pertick,mhz;
int total_execs = 0;
//calculate mhz as below
for (i = 0; i < nspu; i++)
{
cycles_pertick=psp[i].psp_iticksperclktick;
mhz = (cycles_pertick*ticks_per_sec)/1000000;
(void)printf("%" PRId64 " MHz #%d\n",mhz,i);
}
}
else
perror("pstat_getprocessor");
}
else
perror("pstat_getdynamic");
}
11.6 Determining the Current Processor
HP-UX 11i provides two system APIs to determine the current processor on
which your code is running. This information can be useful when using timers or
determining the processor affinity of a process.
The pstat_getproc(2) function returns information specific to a particular
process, including the currently running processor. However, in multithreaded
applications, the process may be running on multiple processors at the same time.
In this case, pstat_getproc( ) will always return the same value.
Multithreaded applications should use the pthread_processor_id_np(3T)
function to determine the current processor. With an argument of
PTHREAD_GETCURRENTSPU_NP the processor the thread is currently running on is
returned. This interface is not portable across platforms and should be used with
caution. Example 11–5 provides an example of its use.
Example 11–5: Determining the Current CPU
#include <stdio.h>
#include <pthread.h>
pthread_spu_t spu_id;
pthread_processor_id_np(PTHREAD_GETCURRENTSPU_NP,&spu_id,0);
printf("%d On CPU: %d\n", pthread_self(),spu_id);
11–6
Hardware Considerations
11.7 Instruction Pointer (Program Counter)
The Instruction Pointer (IP) or Program Counter (PC) is accessible to the
application programmer as a read-only register. In the Itanium® architecture,
instructions are grouped into sets of three instructions called a bundle. When
the IP register is read, it points to the next bundle of instructions to be
executed. As a result, the IP is aligned on 16-byte boundaries. This register is
accessed using the mov instruction.
For example, to access the IP use this assembly code:
mov
r32 = ip
;;
// Access the IP
For more information, see the Intel® Itanium® Architecture Software
Developer’s Manual, Volume 1, Section 3.
11.8 Processor Interval Time Counter
Like Alpha processors, both the PA-RISC and Itanium® processor families provide
a register that counts at a fixed relationship to the processor clock frequency. This
is a read-only register that lets you directly access timing information to determine
application performance. This register is Application Register 44 (AR44) on the
Itanium® processor family and Control Register (CR16) on PA-RISC.
There are several limitations in using this type of timer. The high granularity of
the timer means that other factors, such as cache hits and unrelated I/O interrupts,
may significantly affect the time measured. Additionally, each processor in a
multiple processor system has its own interval timer and they are not required
to be synchronized to each other. Use of the interval timer is only valid on a
uniprocessor system or where the application can guarantee that it is executing on
the same CPU. These limitations generally limit the use of this type of timer to
performance testing during development; for example, how much does optimization
increase the performance of this calculation loop.
Example 11–6 uses the TICKS preprocessor macro to access the ITC on Alpha
processor, PA-RISC or Itanium® processors. This example is also available
for download from the DSPP site: http://www.hp.com/go/dspp under the
Itanium®-based solutions >> technical tips >> performance tools
section.
Example 11–6: Reading the ITC
/*
*
* The TICKS macro can be used to access the high-resolution counters
* on the CPU for timing. These counters increment at a rate based on
* the CPU cycle clock. This does not imply a 1:1 ratio.
*
* Caution needs to be used, particularly when using these macros as
* there is no consideration to overflow or changing CPUs. The counters
* in multi-CPU systems are not required to be in sync and may be
* significantly different.
*
* These timers should only be used for VERY small windows, 1-2
* milliseconds to reduce the risk of these problems. These counters
* return 64-bit integer values and should not be stored in int type
* variables, whenever possible the C99 uint64_t type should be used.
*
*/
#ifndef __TICKS_H_
#define __TICKS_H
Hardware Considerations
11–7
Example 11–6: Reading the ITC (cont.)
#include <inttypes.h>
/* Check for HP Tru64 UNIX compilers */
#if defined(__DECC_VER) || defined(__DECCXX_VER)
/*
* Handle the Alpha Processor Family
*/
#if defined(__alpha)
#include <alpha/builtins.h>
#define __TICKS __RPCC()
#endif /* __alpha */
/* Check for the HP-UX Compilers */
#elif defined(__HP_aCC) || defined(__HP_cc)
#if defined (__STDC_32_MODE__)
#error "Must use +e or -Ae for 64-bit integer support"
#endif /* __STDC_32_MODE__ */
/*
* Handle the Intel Itanium Processor Family
*/
#if defined(__ia64)
#include <machine/sys/inline.h>
#define __TICKS _Asm_mov_from_ar(_AREG_ITC)
/*
* Handle the PA-RISC Processor Family
*/
#elif defined(__hppa)
#if defined (__HP_aCC)
#error "Inline assembler not supported in C++, compile using C"
#endif /* __HP_aCC */
#include <machine/inline.h>
#include <machine/reg.h>
#ifdef __cplusplus
inline
#else /* __cplusplus */
#pragma INLINE __TICKS_f
#endif /* __cplusplus */
static uint64_t __TICKS_f(void) {
register uint64_t _ticks;
_MFCTL(CR16,_ticks);
return _ticks;
}
#define __TICKS __TICKS_f()
#else
#error "Unknown chip for compiler."
#endif /* arch && ( __HP_aCC || __HP_cc ) */
#else
#error "Unknown Compiler"
#endif /* Complier Tests */
#endif /* __TICKS_H */
11–8
Hardware Considerations
11.9 Application Stack
The stack pointer in the Itanium® processor programming convention is stored
in General Register 12 (GR12); the alias of sp can also be used to access the
register. The stack grows downward (from high memory to low memory), the
same direction the stack grows on Tru64 UNIX. Offsets into the stack frame
are positive relative to the current stack pointer. The stack pointer is always
16-byte aligned.
On Itanium®-based systems, the HP-UX 11i library libunwind.so lets you
unwind the procedure call stack. For more information on this library, see
unwind(5).
The PA-RISC versions of HP-UX 11i use General Register 30 (GR30) for
the stack pointer; the alias of sp can also be used to access the register.
PA-RISC-based systems use a stack which grows to higher addresses (up).
Offsets into the stack frame are negative relative to the current stack pointer.
The stack pointer is always 64-byte aligned.
On PA-RISC-based systems, libcl provides a stack unwinding interface.
For more information on this library, see the UNWIND PA64 Functional
Specification at:
http://devresource.hp.com/
drc/STK/docs/archive/unwind.pdf
or Chapter 8: Stack Unwind Library of The 32–bit PA-RISC Run-time
Architecture Document at:
http://devresource.hp.com/drc/STK/docs/archive/rad_11_0_32.pdf
11.10 Register Stack
The Itanium® processor uses stacked register files to improve performance.
The processor can allocate up to 96 general registers for use as a register
stack. The registers in the stack can be renamed in a process called register
renaming. This mechanism is used to pass parameters for function calls. This
allows the parameters to be in the same physical registers in both the calling
and the called function’s register stack frame. In other words, the output
parameters of the calling function become the input arguments to the called
function and are stored in the same registers. The registers are automatically
renamed in the called function to facilitate this operation. This reduces the
overhead of function calls.
The register stack can be configured as a circular buffer with register
renaming. If all the registers are used when a function is called, then the
contents of previously used registers are spilled to memory by the Register
Stack Engine (RSE). As the stack is unwound, the previous contents of the
registers are restored by the RSE.
The register stack can also be used in software pipelining and loop unrolling.
The various uses of register renaming allows the compiler to increase the
efficiency of a section of code. The renaming of registers is transparent to
the application programmer, but knowledge of this allows you to facilitate
the efficient use of these resources.
For more information, see the Intel® Itanium® Architecture Software
Developer’s Manual, Volume 1, Sections 2 and 5.
11.11 Floating Point
Both the Itanium® and PA-RISC processors provide hardware support for two
floating-point data types as well as instructions for converting between the types:
•
Single-precision floating-point
Hardware Considerations
11–9
•
Double-precision floating-point
The Itanium® processor also provides hardware support for two additional
types:
•
82-bit floating-point
•
SIMD or parallel floating-point
Additionally the double-extended real (IEEE real type, 128-bit) floating-point
format is supported. Depending on the implementation of the architecture, the
IEEE-style quad-precision (128-bit) data type may be supported in either hardware
or software.
Both methods of IEEE rounding precision are supported: converting the result to
the double-extended exponent range and converting results to the destination
precision. There are four rounding modes supported:
•
Nearest (or even)
•
-infinity (down)
•
+infinity (up)
•
Zero (truncate/chop)
There are two functions in HP-UX 11i to select rounding modes:
fegetround(3)
Gets the current rounding mode.
fesetround(3)
Sets the rounding mode.
The macros to define the mode are contained in /usr/include/fenv.h. The
default mode is round to nearest. The similar functions in Tru64 UNIX are
read_rnd(3) and write_rnd(3). Rounding modes can also be selected with the
HP-UX 11i -fpeval compiler option, which is similar to the Tru64 UNIX -fprm
option on both Compaq C and Compaq Fortran.
11–10
Hardware Considerations
The Itanium® architecture allows lower-precision operands to produce higher
precision results as suggested in the IEEE standard. The architecture also
allows higher-precision operands to produce lower-precision results. This is an
extension to IEEE standard suggestions in this area. (The standard suggests
that this type of operation not be allowed.) When these types of operations
produce values beyond the ability of the lower-precision to represent, the
floating-point status registers are updated to reflect this.
Itanium® processors use 82 bits internally to store floating-point values;
Alpha processors use 64-bit internal representations. The Itanium® processor
transforms the internal representation to the desired output representation
when the value is stored from a register to a memory location. This allows
higher-precision while manipulating values in registers, and the desired
precision is achieved in the result stored in memory. In addition to the IEEE
formats, Itanium® processors support IA-32 formats and can also store values
using the register format in memory.
The floating-point registers contain three fields:
•
A significand in the lower 64 bits (b0-b63), which is composed of one bit
for an explicit integer bit (b63) and 63 bits for the fractional part of the
significand (b0-b62).
•
A 17-bit exponent (b64-b80). The exponent is biased by 65536 (0xFFFF).
An exponent of all ones is used to encode IEEE signed infinity and NaNs.
An exponent field of all zeros and a significand field of all zeros is used to
encode IEEE signed zeros. An exponent field of all zeros and a nonzero
significand field encodes the double-extended real denormals and a
double-extended real pseudo-denormals.
•
A one-bit sign bit (b81). When floating-point values are stored from
registers to memory, they are formatted using the standard IEEE memory
formats: single (4 bytes), double (8 bytes), and double-extended (10 bytes).
The floating-point registers are used for all floating-point operations and for
integer multiply and divide operations (unless the compiler realized it can use
shifts). The Itanium® processor does multiplication in hardware, but uses
software to perform division, square roots, and remainders. Intel® provides the
algorithms and machine code to implement these operations. For applications,
these operations are automatically provided by the compiler/libraries.
Using 82 bits in the floating-point registers allows both reals and integers to
be stored in the 64-bit significand. The 17-bit exponent, instead of 15 bits
as in the IEEE format, allows the Newton-Raphson approximations used in
software divide/sqrt to be seeded with reciprocal approximation instructions
that call handlers if they are not conformant 80-bit numbers (that is, a 15-bit
exponent cannot represent the value). This allows the calculations to occur
without conditionals in the Newton-Raphson. These extra bits can also be
used to simplify the implementation of some basic numeral algorithms.
There are several advantages to implementing the divide/sqrt operations
in software. One advantage is that because the complex operations are
implemented by a series of simpler instructions, these instructions can be
scheduled along with other instructions. This allows the opportunity for
increasing the parallel execution of instructions. Another advantage is the
ability to choose the algorithm used for the calculation. It is possible to
optimize these operations for either speed or accuracy, depending on the
requirements of the application.
Itanium® processors also have a fused multiply-add instruction. This allows
increased precision when chaining several operations together. The processors
also implement several IEEE suggested operations in hardware, including
maximum, minimum, absolute maximum, and absolute minimum.
Hardware Considerations
11–11
11.12 Pagesize Considerations
Applications that require a large amount of memory should consider the significant
performance benefits available from using an increased pagesize. The Alpha,
PA-RISC, and Itanium® designs are different in this area, as are the designs of
HP-UX 11i and Tru64 UNIX. As the amount of memory available to applications
continues to increase, changes will continue to occur in this area.
For proper operation of applications that use pagesize information (mmap(2), private
memory managers, and so on), the information should not be hard-coded into the
application. POSIX.1c defines the sysconf(3) API to retrieve information from the
operating system during execution. Using a _SC_PAGESIZE argument will return
the pagesize currently used by the application.
The Alpha processor uses an 8 KB pagesize; most other processors currently
use a 4 KB pagesize. The Itanium® processor allows for variable pagesizes (see
Table 11–4). HP-UX 11i further extends this by allowing the pagesize to be
controlled on a per-application basis. Use the +pd and +pi linker switches or the
chatr tool (see Section 5.3.2) to select the pagesize you want for your application.
Table 11–4 shows the architecture supported pagesizes. All pagesizes supported
by an architecture may not be supported in individual implementations of that
architecture or by the operating systems running on them.
Table 11–4: Architecture Supported Pagesizes
Pagesize
Alpha Architecture
PA-RISC Architecture Itanium® Architecture
4 KB
Not Available
X
X
8 KB
X
X
X
16 KB
X
X
X
32 KB
X
Not Available
Not Available
64 KB
X
X
X
256 KB
Not Available
X
X
1 MB
Not Available
X
X
4 MB
Not Available
X
X
16 MB
Not Available
X
X
64 MB
Not Available
X
X
256 MB
Not Available
Not Available
X
While the architectures support multiple pagesizes, the operating systems do not.
The core pagesize on HP-UX 11i is 4 KB; Tru64 UNIX uses 8 KB. Under HP-UX
11i the memory-management system can use SuperPages to manage multiple,
adjacent 4 KB pages as a single page. This size is dynamically adjusted during the
program’s execution, and the starting size used is 4 KB unless the +pi or +pd
options or the chatr tool is used to change the default size.
11.13 Atomic Memory Operations
An application executing on a multiprocessor system may need a method for
coordinating data access across multiple instruction streams to ensure data
consistency. For example, you may have a shared memory segment that is
manipulated by multiple processes and needs to be protected by some kind of
voluntary lock. Typically semaphores are used to provide this lock. The semaphore
permits processes to coordinate their access to the shared memory structure, which
prevents data corruption.
11–12
Hardware Considerations
HP-UX 11i provides standard semop(2) semaphores, file-system locking (lockf(3)
and ioctl(3)) and memory-mapped semaphores. These methods work well for
locks that are held for a long period of time, such as when writing to disk. For
locks held for a short period of time, for example when updating to a few words
in a shared memory area, these types of locks can become a severe performance
bottleneck. A spinlock is a much more appropriate construct for mutual exclusion
in a multiprocessor environment, when the lock is to be held for very short periods
of time.
A spinlock is a special class of semaphore. When a process attempts to acquire a
lock via semop( ), the process becomes blocked and is later rescheduled. This
incurs all of the system overhead associated with putting a process to sleep and
later waking it up. Processes acquiring a lock via spinlock attempt the lock, and if
blocked spin a few machine cycles and try again. These processes may eventually
become voluntarily blocked and go to sleep, but only after many rapid attempts to
acquire the lock.
This time spent spinning is wasted time, but the cost of spinning is much lower
than the cost of blocking and rescheduling the process. Also, since a waiting process
is spinning on a lock, it can acquire the lock immediately when it is released.
Furthermore, a spinlock can be implemented in user code, while a semaphore call
is a system call, which has more overhead and causes a context switch. Thus,
on both uniprocessor and multiprocessor systems, the performance of many
applications that need to hold a lock for very quick memory-to-memory operations
can be greatly enhanced by replacing semaphores with spinlocks.
11.13.1 High-Level Language Support
Tru64 UNIX provides a series of compiler built-ins to provide low-level memory
access for implementation of spin locks and semaphores. Similar constructs are not
provided by default but may be created on HP-UX 11i using the assembler.
11.13.2 Assembly Spinlocks for PA-RISC
User spinlocks in PA-RISC are accomplished by using the load-and-clear
instructions (ldcw or ldcws), which perform the spinlock load-and-clear
operation in a single machine code instruction. Example 11–7 provides a
sample implementation of spinlocks in PA-RISC assembly language.
Example 11–7: PA-RISC Spinlocks in Assembly Language
;
;
;
spin.s:
Example assembly language routine for spinlock support.
.code
.level 2.0W
; use this option for 64-bit assembly
.export load_and_clear,entry,priv_lev=3,rtnval=gr
.proc
load_and_clear
.callinfo no_calls
.enter
;
; create a 16 byte aligned pointer to the load+clear word area
addi
15,%arg0,%arg2 ; add 15 to pointer to round up
; Mask off the lower 4 bits
; Choose one of these statements and comment out the other:
depi
0,31,4,%arg2
; (32-bit version)
;
depdi
0,63,4,%arg2
; (64-bit version)
; load and clear the spinlock.
If locked, return 0
Hardware Considerations
11–13
Example 11–7: PA-RISC Spinlocks in Assembly Language (cont.)
stbys,e
0,(%arg2)
ldcws
nop
(%arg2),%ret0
nop
nop
bv,n
.leave
.procend
;
;
;
;
;
;
scrub everyone else.s cache
important for performance
load and clear the spinlock word
3 No-Op instructions
needed for older
HP-PA chips
(%r2)
A complete set of example routines, including high-level access routines, test
programs and instructions, are included in the Implementing Spinlocks on the
Intel® Itanium® Architecture and PA-RISC white paper. This paper describes the
implementation of spinlocks and fences to guarantee memory consistency for
shared memory applications on the Itanium® processor family, as well as PA-RISC
platforms.
Implementing Spinlocks on the Intel® Itanium® Architecture and PA-RISC is
available from the DSPP Web site:
http://h21007.www2.hp.com/dspp/files/unprotected/Itanium/
spinlocks.pdf
11.13.3 Assembly Spinlocks for the Itanium® Processor Family
Example 11–8 shows the assembly code to test and set a lock at a specified
address on Itanium® processors. For the purposes of this example, [lock]
indicates the address of lock. In complete code, the address would be loaded
into a register that would then be used in Example 11–8.
Example 11–8: Spinlock Code for Itanium® Processors
// Tests the lock at the specified address ([lock]),
// if it is 0 it is available. If it is 1, another
// process is in the critical section.
//
spin_lock:
mov ar.ccv = 0
// cmpxchg looks for avail (0)
mov r2 = 1
// cmpxchg sets to held (1)
spin:
(p1)
ld8 r1 = [lock] ;;
// get lock in shared state
cmp.ne p1, p0 = r1, r2 // is lock held (lock == 1)?
br.cond.spnt spin ;; // yes continue spinning
(p1)
// attempt to grab lock
cmpxchg8.acq r1 = [lock], r2 ;;
cmp.ne p1, p0 = r1, r2 // was lock empty?
br.cond.spnt spin ;;
// continue spinning
cs_begin:
// critical section goes here
cs_end:
st8.rel[lock] = 0 ;;
// release the lock
11–14
Hardware Considerations
A complete set of example routines, including high-level access routines, test
programs and instructions, are included in the Implementing Spinlocks on the
Intel® Itanium® Architecture and PA-RISC white paper, located at:
http://h21007.www2.hp.com/dspp/files/unprotected/Itanium/
spinlocks.pdf
For more complex algorithms to achieve data access synchronization, see Section
13 of the Intel® Itanium® Architecture Software Developer’s Manual; Volume 2:
http://developer.intel.com/design/itanium/manuals.htm
11.14 References
Intel® Itanium® Architecture Software Developer’s Manual, Volumes 1 & 2, revision
2.1, October 2002:
http://developer.intel.com/design/itanium/manuals.htm
Intel® Itanium® Architecture Assembly Language Reference Guide, 2000-2001:
http://developer.intel.com/software/products/
opensource/tools1/tol_whte2.htm
HP-UX Floating-Point Guide, Edition 5, November 1997:
http://docs.hp.com/en/dev.html#Performance%20Tools%20and%20
Libraries
Implementing Spinlocks on the Intel® Itanium® Architecture and PA-RISC, Tor
Ekquist and David Graves:
http://h21007.www2.hp.com/dspp/files/unprotected/Itanium/
spinlocks.pdf
PA-RISC 2.0 Architecture, Gerry Kane, Prentice Hall; ISBN: 0-13-182734-0; 1st
Edition, 1995.
HP-UX Assembler Reference Manual:
http://docs.hp.com/en/dev.html#Assembler
PA-RISC 2.0 Architecture, Hewlett-Packard Company:
http://www.hp.com/dspp >> Technical Resources >> References and Manuals
>> PA-RISC section
Hardware Considerations
11–15
12
Endianism Considerations
This chapter discusses the issues involved when migrating code and data between
computer architectures that have different byte ordering.
12.1 Overview
A significant problem customers and ISVs will have to deal with when migrating
their application and databases from Tru64 UNIX to HP-UX 11i is endianism.
Endianism refers to the way in which data is stored, and defines how bytes are
addressed in multibyte data types. This is important because if you try to read
binary data on a machine that is of a different endianism than the machine that
wrote the data, your results will be different. This is an especially significant
problem when a database needs to be moved to a different endian architecture.
There are two types of endian machines: big-endian (forward byte ordering or
Most Significant First, MSF) and little-endian (reverse byte ordering or Least
Significant First, LSF). The mnemonics of "Big End In" and "Little End In" can be
useful when discussing endianism. Figure 12–1 and Figure 12–2 compare the two
byte ordering methodologies graphically.
Figure 12–1: Big-Endian Byte Ordering
Bit 31
Bit 0
Byte 0
Byte 1
Byte 2
Byte 3
ZK-1959U-AI
Figure 12–2: Little-Endian Byte Ordering
Bit 31
Bit 0
Byte 3
Byte 2
Byte 1
Byte 0
ZK-1960U-AI
On a little-endian operating system (Tru64 UNIX), the little end, or least-significant
byte is stored at the lowest address. This means a hexadecimal like 0x1234 is
stored in memory as 0x34 0x12. The same is true for a 4-byte value; for example,
0x12345678 is stored as 0x78 0x56 0x34 0x12. A big-endian operating system does
this in the reverse fashion, so 0x1234 is stored as 0x12 0x34 in memory.
Consider the number 1025 (2 to the tenth power plus one) stored in a 4-byte
integer. This is represented in memory as shown in Example 12–1.
Endianism Considerations
12–1
Example 12–1: Binary Representation of 1025
little endian:
00000000 00000000 00000100 00000001b
big endian:
00000001 00000100 00000000 00000000b
Like the Alpha processor, the Itanium® processor family supports both big- and
little-endian memory addressing. The PA-RISC processor uses a big-endian
addressing model. HP-UX 11i has always been a big-endian operating system, and
will continue to be so. This means that applications already on HP-UX 11i will be
able to read their existing binary data without modification. The Tru64 UNIX
operating system is little-endian based, so applications running on HP-UX 11i may
not be able to read binary data created on Tru64 UNIX without modification.
Converting data between these two types of systems is often referred to as the
NUXI problem. Imagine the word UNIX stored in two 2-byte words. In big-endian
systems, it is stored as UNIX. In little-endian systems, it is stored as NUXI.
12.2 Persistent Data
Byte order should be considered carefully when reading or writing data. Multibyte
values should be preprocessed such that the endian type of the source and
destination systems is unimportant. Consider the following code example, which
assumes systems implementing the same endianism will be used for both writing
and reading data:
Writer Code:
#include <unistd.h>
#include <inttypes.h>
int64_t val = 1;
ssize_t result = write( fileDes, &val, sizeof( val ) );
Reader Code:
#include <unistd.h>
#include <inttypes.h>
int64_t valRead;
ssize_t result = read( fileDes, &valRead, sizeof( valRead ) );
When both the reader and writer systems are of the same endian type, the contents
of valRead will be 1. However, in situations where the reader and writer have
different byte ordering, valRead will be 0x0100000000000000.
Applications that store persistent data in native endian format will need to be
redesigned to avoid endian issues in shared or migrated data sources. Conversion
of the old data is best handled by a separate process, which allows the primary
application to remain focused on endian-neutral development. There are several
means of handling data storage in endian-neutral formats:
1.
Store the data in a defined endian format.
2.
Add additional data to indicate format.
3.
Store all data as ASCII strings.
The first method is the preferred method as it requires the least overhead.
Storing the data in a defined endian format can be achieved by developing
endian-neutral I/O functions. You can develop I/O functions by:
•
12–2
Using compile-time controls
Endianism Considerations
•
Using run-time controls
•
Using standardized data format functions (by using htons( ) and similar
functions)
The following sections describe each of these methods.
12.2.1 Preprocessor Controlled Byte Order
While the preprocessor can be used to control functions that need to be
implemented differently based on endianism, it is not standardized. None of the
current standards require that the compilers provide a means of determining the
endianism. However, this does not mean that it cannot be done. Developers who
wish to do this must implement their own means of determining the endian type
of a platform.
Compaq C and Compaq C++ provide no default definition, but the inclusion of
machine/endian.h will define BYTE_ORDER. HP-UX 11i has no such header file,
although the HP C and HP aC++ compilers provide the definition of _BIG_ENDIAN.
Therefore, there is no common means of testing byte-order in the preprocessor.
Example 12–2 provides one example of how you might develop code to handle
this situation.
Example 12–2: Supporting Multiple Byte Orderings Using The Preprocessor
#ifndef BIG_ENDIAN
#define BIG_ENDIAN 4321
#endif
#ifndef LITTLE_ENDIAN
#define LITTLE_ENDIAN 1234
#endif
#ifndef BYTE_ORDER
#if defined(_BIG_ENDIAN) || defined(__hpux)
#define BYTE_ORDER BIG_ENDIAN
#else if defined(__osf__) || defined(__linux)
#define BYTE_ORDER LITTLE_ENDIAN
#endif
#endif /* BYTE_ORDER */
.
.
.
#if BYTE_ORDER == BIG_ENDIAN
/* some code depending on big-endian byte ordering */
.
.
.
#else
/* some code depending on little-endian byte ordering */
.
.
.
#endif
12.2.2 Run-Time Byte Order Control
Another means of developing endian-aware code is to dynamically test for the
endian type at run time. By taking advantage of what is normally an endian
bug in software, it is possible to detect the endian type of the running system.
Endianism Considerations
12–3
Example 12–3 shows how you can check to see if your code is running on a little- or
big-endian system. Using the routine in Example 12–3 to check the endian order,
implement your code so that at run time it dynamically acts on either little- or
big-endian data.
Example 12–3: Testing Byte Order
#include <inttypes.h>
bool TestBigEndian(void)
{
int16_t one = 1;
char *cp = (char*)&one;
if ( *cp == 0 ) {
return true;
}
return false;
}
12.2.3 Using Standard Byte Order APIs
Using standardized endian-related APIs will ensure that your code is portable.
One such set of APIs is the host-to-network family. By storing your application
data using these APIs, you ensure that the data is stored in big-endian (network
byte-order) and is therefore more portable than an endian-native format.
The host-to-network/network-to-host byte order conversion functions ( htons(3),
htonl(3), ntohs(3), and ntohl(3)) are highly optimized and should reduce to
only a few instructions on little-endian systems, and may be optimized away on
big-endian systems. Example 12–4 uses the htons( ) function to convert a 16-bit
integer from host byte order to network byte order.
Example 12–4: Using the htons Routine
#include <inttypes.h>
int16_t w = 0x1234;
printf("Host Order w=%04x\n",w);
printf("Network Order w=%04x\n",htons(w));
Example 12–5 uses the htonl( ) function to convert an unsigned 32-bit integer
from host byte order to network byte-order.
Example 12–5: Using the htonl Routine
#include <inttypes.h>
int32_t w = 0x12345678;
printf("Host Order w=%08x\n",w);
printf("Network Order w=%08x\n",htonl(w));
One problem with the host-to-network APIs is that they are still unable to
manipulate 64-bit data elements. Using information from Example 12–2 and
Example 12–8 it is possible to develop your own 64-bit version of these APIs.
Example 12–6 shows one possible implementation.
12–4
Endianism Considerations
Example 12–6: 64-Bit Host To Network Implementation
#include <inttypes.h>
uint64_t htonq(uint64_t input)
{
#if BYTE_ORDER == LITTLE_ENDIAN
return SWAP_8_MACRO(input);
#else
return input;
#endif
}
uint64_t ntohq(uint64_t input)
{
#if BYTE_ORDER == LITTLE_ENDIAN
return SWAP_8_MACRO(input);
#else
return input;
#endif
}
12.3 Byte Swapping
If data with multibyte values needs to be transferred between little-endian and
big-endian systems, you must provide code that swaps the byte order. For network
or socket communications, use the host-to-network APIs (htons(3), htonl(3),
ntohs(3), and ntohl(3)). Unfortunately, this is a problem that cannot be solved
without knowledge of the data structure layout. The reason is that the manner in
which you swap depends on the format of your data. Character strings typically
do not get swapped, 64-bit elements get swapped eight bytes end-for-end, and
32-bit elements get swapped four bytes end-for-end. Any program that needs to
swap data around needs to know the data type, the source data endian order, and
the host endian order.
The following types of I/O are transparent to endianism and do not need swapping:
•
Data that is a buffer, which is really an array of bytes, because you want the
byte at the lowest address to stay at the lowest address.
•
Data that is read and written by the C++ framework classes.
The framework classes always store data on disk in a type-tagged, compressed
binary format. The processing is such that either machine kind can read or
write data. The on-disk format is the same for both types of machines.
•
Temporary files that are written then read by the same invocation of an
application and that are deleted before the application terminates.
Another way to swap bytes is to use the the swab(3) (swap bytes) API. The syntax is:
void swab(
const void *src,
void *dest,
ssize_t nbytes);
You can also define a preprocessor macro. For 32-bit data, the code to convert
little-endian to big-endian data might look as shown in Example 12–7.
Example 12–7: 32-Bit Endian Byte Swap Macro
#include <inttypes.h>
#define SWAP_4_MACRO(value)\
((( (value) & UINT32_C(0x000000FF))
(( (value) & UINT32_C(0x0000FF00))
(( (value) & UINT32_C(0x00FF0000))
(( (value) & UINT32_C(0xFF000000))
<<
<<
>>
>>
24) | \
8) | \
8) | \
24))
Endianism Considerations
12–5
The macro to swap the byte order of 64-bit data is shown in Example 12–8.
Example 12–8: 64-Bit Endian Byte Swap Macro
#include <inttypes.h>
#define EVENBYTESL UINT64_C(0x00FF00FF00FF00FF)
#define ODDBYTESL UINT64_C(0xFF00FF00FF00FF00)
#define EVENWORDSL UINT64_C(0x0000FFFF0000FFFF)
#define ODDWORDSL UINT64_C(0xFFFF0000FFFF0000)
#define SWAP_8_MACRO(value) \
(((((((((value)>>8) & EVENBYTESL)
(((value)<<8) & ODDBYTESL))>>16) &
((((((value)>>8) & EVENBYTESL)
(((value)<<8) & ODDBYTESL))<<16) &
((((((((value)>>8) & EVENBYTESL)
(((value)<<8) & ODDBYTESL))>>16) &
((((((value)>>8) & EVENBYTESL)
(((value)<<8) & ODDBYTESL))<<16) &
| \
EVENWORDSL) | \
| \
ODDWORDSL))>>32 ) | \
| \
EVENWORDSL) | \
| \
ODDWORDSL))<<32 ))
12.4 Unused Bytes
Sometimes code that tries to make efficient use of memory takes advantage of
the fact that often not all four bytes in an integer are used. For example, if a
particular int field in a record will hold only values in the range 0 to 10,000,000,
the most-significant byte will always be 0. Rather than adding another element
to a structure, the free byte is often used to store an element only requiring 1
byte of storage.
If the most-significant byte is accessed by means of a character array or by casting
and dereferencing a pointer, then the code will not be portable and slightly different
versions will be needed on big-endian and little-endian machines. Example 12–9
shows a sample of this direct byte access.
Example 12–9: Direct Byte Access
#include <inttypes.h>
typedef union freebyte {
int32_t intdata;
char
chardata[4];
} mystruct;
#define set_int(s, x) \
(s).intdata = (((s).intdata&0xFF000000)|(x&0x00FFFFFF))
#define get_int(s) ((s).intdata & 0x00FFFFFF)
/* The char accessors are endian specific! */
#define set_char(s, x) (s).chardata[3] = x
#define get_char(s) (s).chardata[3]
However, implementing it as a named bit field will enable the compiler to generate
the correct instructions regardless of the endianism. This problem can be corrected
as shown in Example 12–10.
Example 12–10: Named Bit Fields
#include <inttypes.h>
typedef struct freebyte {
int32_t _3byte:24;
int32_t _1byte:8;
} mystruct;
#define set_int(s, x) (s)._3byte = x
12–6
Endianism Considerations
Example 12–10: Named Bit Fields (cont.)
#define get_int(s) (s)._3byte
#define set_char(s, x) (s)._1byte = x
#define get_char(s) (s)._1byte
Using bit fields in this manner grants the same memory footprint reduction and
removes endianism problems. It also makes it possible to remove the accessor
macros as each element is now a legal element.
12.5 Unions
Applications that utilize unions and make assumptions about the data layout
within that union will have endian portability problems. Example 12–11 shows
one such union.
Example 12–11: Endianism and Unions
#include <inttypes.h>
union int_byte {
int32_t int_val;
char byte[4];
};
union int_byte my_var;
my_var.int_val = 1000000;
if(my_var.byte[3] == 0)
printf("The number is divisible by 256\n");
On a big-endian machine, this code works correctly. byte[3] is 0 only when the
number is 0 or a multiple of 256. However, on a little-endian machine, byte[3]
is the most-significant byte. The easiest way to avoid this problem is not to
try and outsmart the compiler. The same functionality can be achieved using
endian-independent code. For example:
if((my_var.int_val & 0xFF) == 0)
printf("The number is divisible by 256\n");
Or, better still:
if((my_var.int_val % 256) == 0)
printf("The number is divisible by 256\n");
12.6 Initializing Multiword Entities in 32-Bit Chunks
Use care when porting code that initializes multiword entities with 32-bit entities.
For example, on a little-endian system, an array of two 32-bit integer values is
used to initialize a 64-bit double:
u.ul[0] = 0x7FFFFFFF;
u.ul[1] = 0xFFFFFFFF;
To produce the correct results on a big-endian system, such as on HP-UX 11i, the
subscripts must be reversed to represent the correct byte-order. For example:
u.ul[1] = 0x7FFFFFFF;
u.ul[0] = 0xFFFFFFFF;
When possible, data elements should always be initialized using their natural type.
The language standards include support for constant initializers large enough to
initialize the largest supported data types. The limits.h and float.h header
Endianism Considerations
12–7
files contain information on the sizes as well as the macros for maximum and
minimum values for numeric data types as defined by the ANSI C standard.
12.7 Hex Constants Used as Byte Arrays
An endian problem occurs when a 32-bit value is often treated as a 32-bit value (an
integer) and sometimes as an array of 4 characters. For example, the following
array is equivalent to the number 0x44332211 on little-endian machines and the
number 0x11223344 on big-endian machines:
char a[4] = {0x11, 0x22, 0x33, 0x44};
Values that are masked using constants can also affect the result when a particular
byte order is expected.
12.8 Other Considerations
There is a trick in common use in little-endian code that is forbidden in
cross-platform work: casting a pointer to an int to a pointer to a char and
assuming that the least-significant byte will be at the address pointed to. For
example:
unsigned int value = 0x03020100
unsigned int *ptr = &value;
unsigned char charVal;
charVal = *(unsigned char*)ptr;
On a little-endian system charVal is assigned the value of 0. On a big-endian
system it is assigned the value of 3. You do not want to use such code in your
program but it is very common. In old code written for a little-endian platform it is
one of the hardest things to find and root out.
To accomplish the same thing in a portable way, use a temporary variable:
unsigned int temp = *ptr;
charVal = (unsigned char)temp;
The second line will take its value from the least-significant byte on every
architecture whether it is at the high or low end of the temporary variable; the
compiler handles the details for you.
Also, you should do endian conversion on input and output and not in the middle of
compute routines. This may be obvious but it is sometimes overlooked.
12.9 Conclusion
Unfortunately, byte-swapping may be necessary when moving data between
different architectures. However, it does not have to greatly affect the performance
of your code. The code required to swap a two-, four-, or eight-byte value is just a
few instructions and is easily done entirely in the registers. If you have significant
data to swap, such as large arrays, all of the code should fit in a small loop that fits
well in the cache, and the data can be fetched sequentially from the data cache,
which is very efficient. Just be sure to understand the format of your data before
migrating your code and you will not have any problems with data integrity.
12–8
Endianism Considerations
13
Libraries and APIs
This chapter discusses the differences in system libraries, their associated APIs,
and some information on developing your own libraries. For more information on
system libraries and APIs, see the reference pages, release notes, and the HP-UX
Linker and Libraries User’s Guide.
On Tru64 UNIX, excutables and libraries use a variant of the System V Common
Object File Format (COFF) standard known as eCOFF (extended COFF). This is
true for both 32-bit (IP32) and 64-bit (LP64) images. HP-UX 11i supports two
different formats, depending on architecture and memory model.
Prior to supporting a 64-bit operating system version, HP-UX used a proprietary
object file format, System Object Module (SOM). With the addition of 64-bit
support, HP-UX adopted a new standard for its 64-bit images, Executable and
Linking Format (ELF). For binary compatiblity, 32-bit PA-RISC excutables and
libraries continue to use SOM. When HP introduced HP-UX for Itanium®-based
systems, the new version of the operating system chose to use ELF for both 32-bit
and 64-bit images.
The use of system archive libraries was deprecated in HP-UX11.0; HP-UX 11i
has removed many of the system archive libraries. HP-UX 11i v1.5 and later do
not provide system archive libraries for Itanium®-based systems. While archive
libraries are provided on HP-UX 11i v2 for PA-RISC platforms, not all archive
libraries are available in both 32-bit and 64-bit forms. HP recommendeds that
you update your application to use shared libraries. Shared libraries offer the
following benefits:
•
Shared libraries avoid binding architecture dependencies into the
application. This is especially important for PA-RISC applications running
on Itanium®-based systems.
•
Defect fixes are automatically picked up when a library is patched.
•
Increased portability across operating system releases, and new performance
and functionality improvements are immediately available without having
to recompile.
The move to shared libraries was introduced to reduce the number of issues caused
by symbol collisions between archive and shared libraries. HP-UX 11i and Tru64
UNIX both use dynamically bound applications by default.
13.1 APIs
This section discusses APIs that are available on Tru64 UNIX and are not available
or have different behaviors on HP-UX 11i. Many of these are BSD-specific APIs
that have been replaced by POSIX interfaces or areas where the standard is not
specific.
Details on specific APIs can be found in the appropriate reference pages. Unlike
Tru64 UNIX, which uses primarily just numbers to denote reference sections,
HP-UX 11i uses both numbers and letters to provide a finer granularity. Table 13–1
describes the major reference page groups for HP-UX 11i APIs.
Libraries and APIs
13–1
Table 13–1: System APIs Library Availability
Reference
Section
Description
Location
System Calls
libc
3C
Standard libc routines
libc
3S
Standard I/O routines
libc
3M
The math library
libm
3N
Networking library routines
libnsl, libnisdb,. libc
3T
Pthread library routines
libpthread
3E
Elf library routines
libelf
3G
The graphics library
Graphics library
3I
The instrumentation library
Instrumentation support library
3X
Various specialized libraries
Library names documented in the
reference pages
2
13.1.1 Tru64 UNIX Migration Libraries
The Tru64 UNIX Migration Environment for HP-UX (Migration Environment)
provides a partial set of APIs to mimic certain Tru64 UNIX behaviors on HP-UX
11i. More information on the Migration Environment is available from:
http://www.hp.com/go/tru64appmigration
The Migration Environment supports both 32- and 64-bit environments. The
libraries provided by the Migration Environment contain a selected set of Tru64
UNIX based APIs to assist developers porting applications to HP-UX 11i. These
libraries are automatically linked with your application when it is compiled or
linked using the cc or ld drivers, also provided in the Migration Environment.
Applications developed using the Migration Environment libraries will be required
to ensure that these libraries are installed as part of their application installation.
The Migration Environment includes both a shared library, libtru64.so, as well
a static library, libtru64_ext.a. In version 1.3 (and earlier versions) of the
Migration Environment, the shared library, libtru64.so, contained APIs under
consideration for native implementation in future releases of HP-UX 11i. Many of
these APIs have been implemented in the base operating system as of the HP-UX
11i v2 May 2005 release. Starting with version 1.4 of the Migration Environment,
libtru64.so has been replaced with a symbolic link to the base operating system
library, libcext.so, which contains many of the APIs formerly in libtru64.so.
The remainder of the libtru64.so APIs have been moved to the Migration
Environment static library, libtru64_ext.a. Interfaces in libtru64_ext.a are
not expected to be implemented as native APIs in HP-UX 11i.
These libraries are provided to make the migration of your Tru64 UNIX application
to a native HP-UX 11i application easier. Those applications requiring APIs
provided in libtru64_ext.a should continue to investigate alternatives to
migrate their application to a completely native HP-UX 11i version.
13.1.2 Library Comparison
The system run-time library (libc) provides similar functionality on both Tru64
UNIX and HP-UX 11i. Both Tru64 UNIX and HP-UX 11i provide UNIX 95 and
at least partial UNIX 98 compliance. Applications developed based on these
standards are highly portable. Due to the size, a direct comparison of all APIs is
beyond the scope of this guide. The Tru64 UNIX to HP-UX Software Transition
13–2
Libraries and APIs
Kit includes an API analyzer that can be used for this task. The Tru64 UNIX to
HP-UX Software Transition Kit is available for download from:
http://devresource.hp.com/STKT/
Statically linking libc is not supported on HP-UX 11i v1 and is not available on
HP-UX 11i v1.6 and later for Itanium®-based systems. A small archive library,
libcres.a, is provided for customers running performance-critical applications
who wish to link statically.
Beginning with HP-UX 11i v1.5 for Itanium®-based systems, the linking with
libcres.a is handled automatically when an application includes the appropriate
header file for the provided API, for example, string.h for strcpy( ). It is
required to include the relevant header files to take advantage of the library. When
the header files are not included, libcres routines are not linked in, even if this
library is explicitly linked.
The functions included in libcres.a are as follows:
abs( )
bsearch( )
div( )
ffs( )
insque( )
labs( )
ldiv( )
memchr( )
memcmp( )
memcpy( )
memmove( )
memset( )
strcat( )
strchr( )
strcmp( )
strcpy( )
strcspn( )
strlen( )
strncat( )
strncmp( )
strncpy( )
strrchr( )
strspn( )
strstr( )
swab( )
The functions in libcres cannot be preempted but libc functions can be.
Therefore, user libraries cannot contain functions with these names when using
libcres. Detailed information on the use of libcres.a is available from the
libcres.a(5) reference page.
The math library (libm) on HP-UX 11i v2 provides C99 math compliance. HP-UX
11i v1 does not currently provide full C99 math support. HP aC++ provides support
for float (32-bit), double (64-bit), extended (80-bit), and long double (128-bit)
floating-point calculations. The extended type is not enabled by default and
requires the -fpwidetypes option. For more detailed information about the math
library on Itanium®-based systems, see:
http://www.hp.com/DSPP -> Itanium®-based solutions -> Technical
Papers -> Technical Papers : more -> The libm library and
floating-point arithmetic for HP-UX on Itanium®-based systems
A similar document for PA-RISC-based systems is also available:
http://docs.hp.com/en/B3906-90006/index.html
By default, Tru64 UNIX sets the errno values for the math functions. The
default on HP-UX 11i is for the math functions to not set errno, allowing for
better performance. Applications requiring this functionality should use the
+Olibmerrno option. HP Fortran also uses libm for its math functions; support is
included for real*4 (32-bit), real*8 (64-bit), and real*16 (128-bit) floating-point
calculations.
Tru64 UNIX provides the dlopen(3) family of routines in libc. On HP-UX 11i the
additional library of libdl (-ldl) is required.
13.1.3 Memory Management
The return value of malloc(3) when passed a zero (0) is undefined by the standards.
Tru64 UNIX returns NULL in this case; HP-UX 11i returns a valid pointer.
Libraries and APIs
13–3
It is possible for 64- and 32-bit applications to share a memory region. On Tru64
UNIX both applications live in the 64-bit address space; any memory mapped low
enough in the address space can be accessible to both applications. HP-UX provides
additional options for shmget( ) and mmap( ) to request 32-bit addressable
memory regions.
If a 64-bit application requests a shared memory segment using the shmget(2)
function with the IPC_SHARE32, the segment allocated will be addressable by both
32- and 64-bit applications. A similar function is also available for mmap( ). The
mmap( ) MAP_ADDR32 option will return a 32-bit addressable memory region.
The shmget(2) and mmap(2) reference pages contain more information on the
sharing of memory between 32- and 64-bit applications.
13.1.4 String Manipulation
The string manipulation routines may encounter different behavior on HP-UX 11i
than on Tru64 UNIX. Most of these interfaces can be affected by the state of the
Zero Page, the page of memory beginning at address 0. Tru64 UNIX will trigger
a fatal segmentation fault (SEGV) if a NULL pointer is passed to these APIs. On
HP-UX 11i, reading and writing to the Zero Page are allowed by default. This
behavior is controlled by the -z/-Z options. If Zero Page reads and writes are
allowed, then the string routines will act as though they were handed a zero-length
string. To reduce the differences in these APIs between Tru64 UNIX and HP-UX
11i, use the -z linker option. However, as this is not the default on HP-UX
11i, third-party libraries and applications may not have been tested with this
configuration.
However, the Zero Page state does not affect all of the string routines. The
strcmp( ) function will never trigger a SEGV when passed a NULL pointer; this is
a significant difference from Tru64 UNIX.
13.1.5 Process Tracing
The ptrace( ) function has been deprecated in HP-UX 11i v1 and is not available
for Itanium®-based systems. There is no replacement interface; however, the
ttrace(2) and the pstat(2) family of functions may be able to provide functional
equivalents.
13.1.6 Message Catalogs
Internationalization (I18N) and localization (L10N) message catalogs are included
in the UNIX 98 standard. The SVID gettxt( ) and setcat( ) interfaces have
been deprecated in HP-UX 11i. Use the UNIX 98 catopen(3C) and catgets(3C)
interfaces. For more information on internationalization and localization, see
Chapter 17.
13.1.7 Process Management
Both Tru64 UNIX and HP-UX 11i provide strong POSIX compiliance in the area
of process management. The following sections discuss some pre-POSIX areas or
areas not clearly defined by the standard.
vfork()
There are significant differences in the implementation of vfork(2) between HP-UX
11i and Tru64 UNIX. The Tru64 UNIX implementation uses a Copy-On-Write
(COW) fork( ) to provide the vfork( ) functionality. This allows the child process
to act almost as if a fork( ) was used instead.
13–4
Libraries and APIs
In the HP-UX 11i implementation, the process address space is truly shared.
vfork( ) differs from fork( ) in that the child borrows the parent’s memory and
thread of control until a call to exec(2) or an exit (either by a call to _exit(2) or
abnormally). The parent process is suspended while the child is using its resources.
Normally the vfork( ) function can be used just like fork( ). However, it does
not work to return while running in the child’s context from the procedure that
called vfork( ) since the eventual return from vfork( ) would return to a stack
frame that no longer exists. Also be careful to call _exit(2) rather than exit(2)
when calls to exec( ) fail since exit( ) flushes and closes standard I/O channels,
which will damage the parent process’s standard I/O data structures.
The use of vfork( ) for any purpose except as a prelude to an immediate exec( )
or exit( ) is not supported. Any program that relies upon the differences between
fork( ) and vfork( ) is not portable across systems.
wait3() and wait4()
Tru64 UNIX provides the BSD implementations of the wait3(2) and wait4(2)
functions when _BSD is defined. These interfaces are provided only for backward
compatibility and do not conform to current standards. These implementations
use the union wait structure to return information on the target process. The
POSIX implementation uses an int.
Information on the target process should be retrieved from the int using the
POSIX-defined macros, many of which are available to both the BSD and POSIX
implementations. These macros are documented in both the wait(2) reference
page and the sys/wait.h header file.
13.1.8 System Information
The uname(2) system API and the uname(1) command returns the system node
name. The length of these fields is not defined by any standard. On Tru64 UNIX,
the fields allow a 31-byte null-terminated string. HP-UX 11i uses an 8-byte
null-terminated string. If the node name is longer than eight characters, the value
returned by the uname( ) function or command will be truncated on HP-UX 11i. To
avoid this problem, use system names of eight characters or less. The node name
field is expected to be expanded in a future release of HP-UX 11i.
The utsname structure on HP-UX 11i also contains an additional member:
__idnumber. The __idnumber field contains a unique identification number
within that class of hardware, possibly a hardware or software serial number. This
field contains a null string if there is no identification number.
On Itanium®-based systems this number may not be unique. To get a unique
ID, use the _CS_MACHINE_IDENT option of confstr(3C).
13.1.9 Files and File Handles
Both Tru64 UNIX and HP-UX 11i provide strong POSIX compliance in the area of
file management. The following sections discuss some pre-POSIX areas that are
still in frequent use which may affect porting efforts.
Nonblocking I/O
Applications using the legacy nonblocking or synchronized options for open( ) or
fcntl( ) will need to be built with _HPUX_SOURCE defined. HP recommends that
these applications take this opportunity to move to the POSIX implementations
for these extended options. Table 13–2 provides functional mappings between the
Libraries and APIs
13–5
legacy and POSIX flags. Applications that do not wish to migrate to the POSIX
versions will be required to define _HPUX_SOURCE.
Table 13–2: POSIX Nonblocking I/O
Legacy Flag
POSIX Flag
FNDELAY, O_NDELAY
O_NONBLOCK
FSYNC, O_SYNCIO, FSYNCIO
O_SYNC
FDSYNC
O_DSYNC
FRSYNC
O_RSYNC
FDIRECT
O_DIRECT
Permission Test
Both Tru64 UNIX and HP-UX provide the S_IREAD, S_IWRITE, and S_IEXEC
masks to test file permissions. However, these are platform-specific tests and
should be avoided. Use the POSIX versions, S_IRUSR, S_IWUSR, and S_IXUSR,
when possible. Those applications that do not use the POSIX versions will require
that _HPUX_SOURCE be defined.
13.1.10 File System Entries
Applications that modify or access the file system structures directly will need to
be modified. The BSD file system entry APIs are not available on HP-UX 11i.
These APIs include:
endfsent( )
getfstype( )
getfsent( )
getfsfile( )
getfsspec( )
setfsent( )
Applications requiring access to the file system structures should use the
getmntent(3X) family of APIs.
13.1.11 Error Messages
System error messages have historically been accessible by directly accessing the
global data elements sys_errlist and sys_nerr. Directly accessing these
variables is not supported on either Tru64 UNIX or HP-UX 11i. Error messages
should now be accessed using strerror(3). The strerror( ) function provides
locale-dependent error messages.
13.2 Dynamic Library Loading
Loading an additional shared library during execution can be done in the same
manner for both HP-UX 11i and Tru64 UNIX by using dlopen(3). However, there
are differences in the process as well as some different APIs available.
HP-UX 11i requires that to use dlopen(3), or any of the dl* routines, you must
link with libdl (-ldl). Tru64 UNIX provides these functions in libc; HP-UX
11i does not.
The dlerror(3C) and dlclose(3C) implementations are the same between Tru64
UNIX and HP-UX 11i. HP-UX 11i also provides several additional APIs. The
following sections discuss these new APIs as well as differences in existing Tru64
UNIX APIs.
13.2.1 dladdr
The dladdr(3C) API was added to Tru64 UNIX Version 5.1B and HP-UX 11i v2.
13–6
Libraries and APIs
The dladdr( ) function determines whether the specified address is located within
one of the mapped objects that make up the current application’s address space.
An address is considered to be within a mapped object when it is between the base
address and the end address of that object. If a mapped object fits this criteria,
the loader searches the object’s symbol table to locate the nearest symbol to the
specified address. This information is returned in a Dl_info structure.
The HP-UX 11i v2 implementation of Dl_info contains two additional fields,
dli_bind and dli_type, that contain information on the returned symbols scope
and type as defined in the ELF (elf(3E)) standard.
13.2.2 dlget
The dlget(3C) function retrieves information about a loaded module (program
or shared library) from an index specifying the placement of the load module in
the dynamic loader’s search list. An index of -1 requests information about the
loader. An index of -2 requests information about the program itself. All requests
are restricted to the current process.
If successful, dlget( ) returns a handle for the shared library as defined by the
return value from dlopen( ). On error, a value of NULL is returned. See the
reference pages for more information.
13.2.3 dlgetmodinfo
The dlmodinfo(3C) function retrieves information about a load module from an
index specifying the placement of the load module in the dynamic loader’s search
list. Unlike dlget( ), dlgetmodinfo( ) can retrieve information about a load
module in another process. As with dlget( ), an index of -1 requests information
about the dynamic loader. An index of -2 requests information about the program
file itself.
The fourth argument to dlgetmodinfo( ) is a pointer to a function that will be
used to locate the required information. This argument should be NULL, which uses
the internal functions of the loader to retrieve the information.
If successful, dlgetmodinfo( ) returns a handle for the shared library as
defined by the return value from dlopen( ); otherwise, NULL is returned. The
returned values are type-converted to uint64_t. See the reference pages for more
information.
13.2.4 dlgetname
The dlgetname(3C) function returns the pathname of a loaded module.
A load_module_desc structure, such as the one filled in by a call to
dlgetmodinfo( ), is used to locate the requested object. The additional arguments
are the same as for dlgetmodinfo( ).
On success, a pointer to the name is returned. This value must be copied by the
caller and not used directly; on failure, NULL is returned. See the reference pages
for more information.
13.2.5 dlmodadd
The dlmodadd(3C) function lets you create dynamic functions and register them so
that they can be used for dynamic symbol resolution by other libraries. The loader
will create an unwind header and single entry unwind table for the generated
function. The function is associated with a loaded module, and calls to dlopen( )
and dlsym( ) will be treated as though they were called from the associated
library. If a library is unloaded by dlclose( ), the unwind information of any
Libraries and APIs
13–7
associated functions registered by dlmodadd( ) will be removed. The memory
containing the actual dynamic function is not removed; you need to do this. For
more information, see the reference pages.
13.2.6 dlmodinfo
The dlmodinfo(3C) function retrieves information about a loaded module from
a given address value. It searches all currently loaded modules, all segments,
looking for a module whose address range holds the given address value. If the
requested address is NULL, then information on the loader itself is returned. The
fourth argument is a pointer to a function used by dlmodinfo( ) to retrieve the
requested information. If the value is NULL, the dynamic loader will use its own
internal data structures to find the correct load module and the following two
parameters are ignored. For more information, see the reference pages.
13.2.7 dlmodremove
The dlmodremove( ) function removes the registration and unwind information of
functions registered by dlmodadd( ). It will not free the space used by the unwind
information or by the generated code, which was allocated by the user and must be
freed by the user. For more information, see the reference pages.
13.2.8 dlopen
While the other APIs in the dlopen( ) family are either new or functionally
equivalent, dlopen(3) is not the same on the two operating systems.
Tru64 UNIX uses a slightly different search path with libraries opened with
dlopen( ). The current directory (“.”) is prepended to the search algorithm.
HP-UX 11i does not alter the search algorithm for dlopen( ); only the default
search path is used. This may cause problems for applications that assume that:
dlopen(“libfoo.so”,RTLD_LAZY|RTLD_GLOBAL);
will behave the same as:
dlopen(“./libfoo.so”,RTLD_LAZY|RTLD_GLOBAL);
Also note that since library-level versioning (see Section 13.3.1) must be used, HP
recommends that files opened with dlopen( ) include the full name of the library
not just the simple form. For example:
dlopen(“./libfoo.so.1”, RTLD_LAZY|RTLD_GLOBAL);
as compared to:
dlopen(“./libfoo.so”, RTLD_LAZY|RTLD_GLOBAL);
Both platforms will ignore the value LD_LIBRARY_PATH for setuid/setgid
applications.
HP-UX 11i makes different assumptions for the default behavior of dlopen( ).
Tru64 UNIX assumes RTLD_GLOBAL if neither RTLD_GLOBAL nor RTLD_LOCAL
are provided. HP-UX 11i assumes RTLD_LOCAL. Both assume RTLD_LAZY. The
difference in symbol scope can result in different behavior on both platforms. To
ensure consistent behavior, specify either RTLD_GLOBAL or RTLD_LOCAL explicitly.
In addition to the values supported by Tru64 UNIX, HP-UX 11i v1 and HP-UX
11i v2 support several other scoping options that control which symbols can be
used to resolve dependencies of the loaded library: RTLD_PARENT, RTLD_GROUP,
RTLD_WORLD. These values are not supported on HP-UX 11i v1.6.
Under RTLD_GROUP the specified object and its dependencies will only resolve
symbols using objects loaded in the same dlopen( ). This ensures that no collisions
occur with previously loaded libraries when attempting to load a new object. All
13–8
Libraries and APIs
symbols are resolved from libraries that would have been loaded (previously loaded
libraries are not remapped) from the same dlopen( ) invocation.
The RTLD_WORLD scoping rule ensures that only symbols from global
(RTLD_GLOBAL) objects and the object itself are used for resolution. Symbol
definitions from other objects loaded as part of the dlopen( ) invocation are not
used.
The RTLD_PARENT mode allows symbols from the object that invoked the
dlopen( ) to be used to resolve dependancies.
The default scoping mode is RTLD_GROUP|RTLD_WORLD. These scoping modes are
OR’ed together when an object is loaded multiple times with different modes.
There are also several features that do not affect symbol resolution but provide
some unique functionality. You can use the RTLD_NODELETE and RTLD_NOLOAD
flags to protect or query the loaded libraries. The RTLD_NODELETE flag will protect
the library from being unloaded; any calls to dlclose( ) will silently return
success without actually unloading the library. The RTLD_NOLOAD flag does not
actually load the object. It queries the currently loaded list and returns a handle
to the object if it is already loaded. If the object is not loaded, then dlopen( )
will return an error.
13.2.9 dlsym
HP-UX 11i does not support the passing of a NULL handle to dlsym(3). HP-UX 11i
v1 and HP-UX 11i v2 provide a new special handle of RTLD_SELF that can be used
to resolve a symbol from the calling library using the load order symbol resolution
algorithm. RTLD_SELF is not available on HP-UX 11i v1.6.
Another special handle available in HP-UX 11i v1 and HP-UX 11i v2 is
RTLD_DEFAULT. This special handle performs the symbol search using the scope of
the calling object. For example, if the caller object was loaded with RTLD_GROUP
(see Section 13.2.8), it will not search symbols in objects that were not loaded in the
same dlopen( ) invocation as the caller object. RTLD_DEFAULT is not available on
HP-UX 11i v1.6.
13.2.10 Thread Local Storage
Two thread local storage models are supported for HP-UX 11i on Itanium®-based
systems: static and dynamic. Which model is used is determined by a compiler
option. The default is +tls=dynamic. Shared libraries built with the dynamic
model can be loaded using the dlopen( ) and shl_load( ) APIs. An attempt
to load a shared library built with the static model using either API will result
in an error. An attempt to load the pthread library using dlopen( ) with the
DLD_VERBOSE_ERR loader environment enabled reports the following:
Cannot dlopen load module ’/usr/lib/hpux64/libpthread.so’
because it contains thread specific data.
When DLD_VERBOSE_ERR is not set, no error is reported to the console, the library
fails to load, and the same message is returned by dlerror( ) on a failed attempt
to load a library that contains static TLS data.
This error can be avoided by recompiling the library using dynamic TLS
(+tls=dynamic). It is also possible to change the run-time environment by using
the LD_PRELOAD environment variable to load a shared library built with the static
thread local storage model. HP recommends using dynamic TLS whenever possible.
Libraries and APIs
13–9
13.3 Developing Libraries
This section discusses issues related to the development and support of nonsystem
libraries. Developing libraries requires a complete understanding of the linker and
loader environments. Additional issues that may affect your library are discussed
in Chapter 5.
13.3.1 Versioning Shared Libraries
Tru64 UNIX provides intralibrary versioning (version strings internal to the
library). This functionality is not available on HP-UX 11i; System V library-level
versioning must be used.
Unlike Tru64 UNIX, HP-UX 11i does not automatically set the internal name of a
shared object. You must specify the +h option on the linker command line to set
the internal library name. If there is no internal name provided in the library, the
linker places the primary name of the file (it does not traverse symbolic links)
in the dependency list of the executable. This means that the application will
not use versioned forms of the library, and will always use the file the symbolic
link references at the time of execution.
The internal library name (-soname on Tru64 UNIX and +h on HP-UX 11i) is set
to include the version number. After linking the versioned library name to the .so
name, link your application normally by specifying -lfoo. The linker uses the
internally stored name of the library. If it is not available, the actual file name is
used to construct the application or library’s dependency information. Symbolic
links are not traversed before storing the library name.
In the future, the loader will still find libfoo.so.2 using the stored name from
the dependency information, even if libfoo.so is now linked to another file.
Example 13–1 shows an example of library-level versioning.
Example 13–1: Library-Level Versioning
% ld -b foo.o +h libfoo.so.2 -o libfoo.so.2
% ln -s libfoo.so.2 libfoo.so
% cc +DD64 -lfoo hello.c -o hello
Libraries that provide support for multiple versions will require a new method;
multiple libraries will need to be provided. These may be actual files or symbolic
links to a central library that is versioned as the highest level supported.
Example 13–2 shows an example of library-level versioning for multiple version
support.
Example 13–2: Library-Level Versioning For Multiple Version Support
%
%
%
%
ld
ln
ln
ln
-b
-s
-s
-s
foo.o +h libfoo.so.3 -o libfoo.so.3
libfoo.so.3 libfoo.so
libfoo.so.3 libfoo.so.2
libfoo.so.3 libfoo.so.1
This allows applications requiring prior versions of the libraries to still run, while
newly developed applications will still be linked against the latest version. Extra
care must be taken to ensure that the newer version of the library is completely
compatible with previous versions if this method of versioning is used.
13–10
Libraries and APIs
13.3.2 Dependencies
Unlike Tru64 UNIX, HP-UX compilers do not automatically link their run-time
library dependencies. Instead, the dependencies are resolved at application link
time rather than library link time.
If you wish to ensure that your library includes all its dependent libraries (and
resolves all symbols) without building an application, there are ways to determine
if your library is complete. Use the +allowunsats and +noallowunsats linker
options.
By default, when building a library, unresolved symbols are allowed and not
reported. For example:
$ cc -b -o libhello.so hello.c
The +allowunsats option reports unresolved symbols as warnings:
$ cc -b -o libhello.so -Wl,+allowunsats hello.c
ld: (Warning) Unsatisfied symbol "printf" in file hello.o
ld: (Warning) Unsatisfied symbol "close" in file hello.o
ld: (Warning) Unsatisfied symbol "write" in file hello.o
ld: (Warning) Unsatisfied symbol "open" in file hello.o
ld: (Warning) Unsatisfied symbol "read" in file hello.o
5 warnings.
+noallowunsats reports the unresolved symbols as fatal errors:
$ cc -b -o libhello.so
ld: Unsatisfied symbol
ld: Unsatisfied symbol
ld: Unsatisfied symbol
ld: Unsatisfied symbol
ld: Unsatisfied symbol
5 errors.
-Wl,+noallowunsats hello.c
"printf" in file hello.o
"close" in file hello.o
"write" in file hello.o
"open" in file hello.o
"read" in file hello.o
Another option is to use the ldd tool. The ldd option -r will attempt to resolve all
text and data symbols. Any unresolved symbols will be reported. For example:
$ ldd -r libhello.so
symbol not found:
symbol not found:
symbol not found:
symbol not found:
symbol not found:
printf
(./libhello.so)
close (./libhello.so)
write (./libhello.so)
open (./libhello.so)
read (./libhello.so)
13.3.3 Library Permissions
Unlike Tru64 UNIX, shared libraries on HP-UX 11i must have execute permission
to be mapped at run time. Shared libraries that do not have execute permission
will cause the following run-time error:
/usr/lib/hpux32/dld.so: Mmap failed for library<./libB.so> :
Permission denied.
13.3.4 Support for Weak Symbols
The ELF file format provides support for global, local, and weak symbols.
Creating these symbols requires support from the compiler. The HP C and C++
compilers do not provide support for weak symbols.
Libraries and APIs
13–11
The HP-UX 11i v2 assembler (/usr/ccs/bin/as) provides support using
the .weak directive. Example 13–3 defines weakfunc to be a weak binding
to func. Details on the assembler can be found in the Itanium® Architecture
Assembly Language Reference Guide. You can access this guide from:
http://developer.intel.com/software/products/
opensource/tools1/tol_whte2.htm
Example 13–3: Weak Function Binding Using ASM
.radix
.psr
.psr
C
abi64
msb
.section .text, "ax","progbits"
.global func
.proc
func,weakfunc
.weak weakfunc
func:
weakfunc:
add r10 = -48, sp
add r8 = 0, r0
br.ret.dptk.few rp
.endp
;;
func
13.3.5 The init/fini Routines
Routines used to handle initialization and cleanup (finalization) are referred to as
the init and fini routines, respectively. The method used to specify init and
fini routines is different between HP-UX 11i and Tru64 UNIX. Tru64 UNIX
utilizes both name recognition and linker options to implement init/fini support.
HP-UX 11i uses compiler pragmas and linker options to determine that functions
are init or fini routines. This section discusses implementation of init/fini
routines on HP-UX 11i.
The init routines are called prior to program startup, or when a shared library
is loaded. These routines are defined to take no arguments and return no value.
You can specify init routines by using:
#pragma init "init1"
void init1(void) {
.
.
.
}
You can also specify them on the link line:
ld -b +init init1 +h libfoo.so -o libfoo.so foo.o
The fini routines are called upon return from user code or when a shared library
is unloaded. Like init routines, these routines are also defined to take no
arguments and return no value. You can specify fini routines by using:
#pragma fini "fini1"
void fini1(void) {
.
.
.
}
You can also specify them using the link line:
ld -b +fini fini1 +h libfoo.so -o libfoo.so foo.o
13–12
Libraries and APIs
13.3.5.1 Execution Order
Tru64 UNIX provides a strongly defined means of ordering init/fini routines
when multiple routines exist in a single object by using numerical prefixes. HP-UX
11i relies on the order of command-line options, and the order in that the routines
are defined in source. If you use Tru64 UNIX implicit recognition of the init/fini
routines, then you will need to adopt one of the HP-UX 11i methods. If you use
the explicit recognition (-init/-fini) on Tru64 UNIX, then you may be able
to use the HP-UX 11i +init and +fini options, but the order of execution will
need to be verified.
The order in which the init and fini routines are executed is determined by the
order of discovery. The init routines are run in reverse order of discovery; fini
routines are run in the order they were discovered. Discovery is defined by the
order of the link line, the order of the linker options, and the order of the functions
in the source files. Functions specified on the link line using +init or +fini are
considered discovered in the order they are specified and before any functions
specified using the pragma directives.
13.3.5.2 init/fini Usage
The examples in this section consist of three shared libraries, lib1.so, lib2.so,
and lib3.so. None of these libraries depend on another, and the executable
(init_test) depends on all three libraries.
lib1 (shown in Example 13–4) uses the compiler pragmas to specify initializers
and cleanup routines.
Example 13–4: lib1.c Listing
#include <stdio.h>
#pragma
#pragma
#pragma
#pragma
init
init
fini
fini
"lib1_init1"
"lib1_init2"
"lib1_fini1"
"lib1_fini2"
void lib1() {
printf("lib1\n");
}
void lib1_init1() {
printf("lib1 init1\n");
}
void lib1_init2() {
printf("lib1 init2\n");
}
void lib1_fini2() {
printf("lib1 fini2\n");
}
void lib1_fini1() {
printf("lib1 fini1\n");
}
lib2 (shown in Example 13–5) uses the linker options to specify initializer and
cleanup routines.
Libraries and APIs
13–13
Example 13–5: lib2.c Listing
#include <stdio.h>
void lib2() {
printf("lib2\n");
}
void lib2_init() {
printf("lib2 init\n");
}
void lib2_fini() {
printf("lib2 fini\n");
}
lib3 (shown in Example 13–6) uses both the linker options and the compiler
pragmas to specify initializer and cleanup routines.
Example 13–6: lib3.c Listing
#include <stdio.h>
void lib3() {
printf("lib3\n");
}
#pragma init "lib3_init"
void lib3_init() {
printf("lib3 init\n");
}
#pragma fini "lib3_fini"
void lib3_fini() {
printf("lib3 fini\n");
}
void lib3_init2() {
printf("lib3 init2\n");
}
void lib3_fini2() {
printf("lib3 fini2\n");
}
Example 13–7 shows the impact of using or not using the pragmas. While it
gives you more control as to the order of execution of the init/fini routines, the
compile/link line becomes increasingly complex.
Example 13–7: Building init/fini Sample
% cc +DD64 -b -Wl,+h,lib1.so -o lib1.so lib1.c
% cc +DD64 -Wl,+init,lib2_init -Wl,+fini,lib2_fini -b \
-Wl,+h,lib2.so -o lib2.so lib2.c
% cc +DD64 -b -Wl,+h,lib3.so -o lib3.so \
-Wl,+init,lib3_init2 -Wl,+fini,lib3_fini2 lib3.c
% cc +DD64 -L. -o init_test1 init_test.c -l3 -l2 -l1
% cc +DD64 -L. -o init_test2 init_test.c -l1 -l2 -l3
The order in which these libraries appear on the final application link line is also
important. The order of execution for init/fini routines is determined by link
order. Example 13–8, init_test1, shows one possible execution order.
13–14
Libraries and APIs
Example 13–8: Sample Run Order 1
$ cc +DD64 -L. -o init_test1 init_test.c -l3 -l2 -l1
$ ./init_test1
lib1 init2
lib1 init1
lib2 init
lib3 init2
lib3 init
lib1
lib2
lib3
lib3 fini
lib3 fini2
lib2 fini
lib1 fini2
lib1 fini1
Example 13–9, init_test2, shows another possible execution order.
Example 13–9: Sample Run Order 2
$ cc +DD64 -L. -o init_test2 init_test.c -l1 -l2 -l3
$ ./init_test2
lib3 init2
lib3 init
lib2 init
lib1 init2
lib1 init1
lib1
lib2
lib3
lib1 fini2
lib1 fini1
lib2 fini
lib3 fini
lib3 fini2
Note that in Example 13–8 lib1 is the first to be initialized, and in Example 13–9
lib3 is the first.
In cases where the libraries result in circular dependencies, the order in which the
initialization routines are run is undetermined. The order within a library will not
change; however, the order between libraries may change between runs or even
between the init and fini sequences of a single run.
Libraries and APIs
13–15
14
Graphics Issues
This chapter discusses issues related to porting X Window System and OpenGL
applications from Tru64 UNIX to HP-UX 11i.
14.1 Compiling and Linking X Window System Applications
When building applications that use the X Window System on Tru64 UNIX, no
special -I or -L compiler options are required; all the #include files are located
in the standard /usr/include/ directory tree, and all the libraries are located
in the standard library locations. The only caveat is that the header files are in
an optionally installed subset of the operating system distribution media and you
need to make sure it is installed first.
Building X Window System applications on HP-UX 11i is slightly different. Like
Tru64 UNIX, the X Window System development kit is not installed by default as
part of the base operating system. Under HP-UX 11i the necessary files for X
Windows System development are included in the HP-UX Developer’s Toolkit, and
it will need to be installed by the system administrator. The HP-UX Developer’s
Toolkit is available at:
http://www.software.hp.com/DTDC_products_list.html
On HP-UX 11i, X Window System applications can also be built as either 32- or
64-bit applications. You need to specify at compile and link time whether it should
be a 32- or 64-bit application. For general hints on deciding whether to build your
application as a 64-bit application or a 32-bit application, see Section 2.5.5.
14.1.1 Required Include Files
At compilation time, you may specify an additional include directory,
/usr/include/X11R6/, in your compilation options for X Version 11 header
files. For example:
% cc +DD64 -I/usr/include/X11R6 -c foo foo.c
However, this is not strictly necessary. You may see this done in other applications
already ported to HP-UX 11i in existing Makefiles. In previous versions of
HP-UX 11i, it was possible to develop applications for either X11R5 or X11R6 and
you needed to explicitly specify which version of the X include files you wanted.
In HP-UX 11i, only the X11R6 development environment is supported. Symbolic
links for the old development environment directory structures are in place for
compatibility.
14.1.2 Required Libraries
When linking an X Window System application, it is not necessary to specify any
additional library search paths to the linker. The linker will find the correct X
Window System API libraries in its normal search path, whether the application is
being built as a 32-bit application or a 64-bit application. The correct search path
directory is implicitly passed to the linker based on whether the user passed the
+DD64 option to the compiler and linker on the command line.
Graphics Issues
14–1
14.2 Run-Time Considerations
If you are porting from Tru64 UNIX, note that properly coded X Window System
applications should not make any assumptions about what the default Visual
Class or pixel depth of the RootWindow of the Display is. Historically, most of
the high-end 3D graphics cards supported by Tru64 UNIX were configured at
the factory to have a default Visual Class of TrueColor and a pixel depth of
24 bits per pixel.
In contrast, many HP-UX 11i workstations shipped with graphics cards configured
with an 8-bit PseudoColor visual as the default visual (used by CDE and most
applications) with TrueColor visuals available for applications to use if they
wished. Therefore, if an application being ported uses the default Visual of a
Display, check to ensure that the application does not make any assumptions
about the class and depth of that default Visual. If it assumes that a TrueColor
Visual is the default, the application may have to be modified to either work
correctly with a default PseudoColor Visual, or to choose another appropriate
nondefault Visual at runtime.
14.3 CDE Applications and Itanium®
For HP-UX 11i on Itanium®-based systems, the Common Desktop Environment (CDE) is
actually a set of PA-RISC executables and libraries run under the Aries binary translator.
A set of native 32–bit shared libraries for HP CDE is available to enable customers to port
their 32–bit applications to Itanium®-based systems. The HP-UX Desktop Developer’s Kit
that contains the Itanium® libraries is available for download for free at:
http://www.software.hp.com/portal/swdepot/
displayProductInfo.do?productNumber=HPDesktopDev
No native 64–bit Itanium® executables or libraries are available. Consequently, a
64–bit application that links in any CDE libraries (such as libDtSvc, libDtTerm,
libDtWidget, and others) must be built on PA-RISC systems. These applications will
also have to be run on Itanium® under Aries like the rest of the CDE environment.
14.4 Compiling and Linking OpenGL Applications
To build OpenGL applications on Tru64 UNIX, the header files and run-time
libraries for OpenGL must be installed on the system from the PowerStorm 3D
graphics card driver kit (formerly known as the OPEN3D product). Developing
OpenGL applications on HP-UX 11i also requires installing an optional software
bundle. The HP-UX 11.00 graphics technical computing environment provides the
OpenGL libraries and header files needed to develop OpenGL-based applications
on PA-RISC systems. HP-UX 11i v2 includes the OpenGL development files on the
base OS DVD, the HP-UX Graphics3D Run Time Environment (Graphics3D)
package provides the required libraries and header files.
The HP-UX 11.00 graphics technical computing environment is available for
download at:
http://www.software.hp.com/ER_products_list.html
14.4.1 Required Include Files
The OpenGL Developers Toolkit is installed under the /opt/graphics/
directory. OpenGL applications will need to specify an include directory of
/opt/graphics/OpenGL/include/, in addition to the standard X11 Release 6
include paths in the compilation flags. For example:
% cc +DD64 -I/opt/graphics/OpenGL/include -c foo.o foo.c
14–2
Graphics Issues
14.4.2 Required Libraries
OpenGL applications being linked should specify the appropriate OpenGL library
directory, /opt/graphics/OpenGL/lib/hpux{32|64}/, as an additional library
directory (-L ) to the linker. For example:
% cc +DD64 -I/opt/graphics/OpenGL/include \
-L/opt/graphics/OpenGL/lib/hpux64 -o foo foo.c \
-lGLU -lGL -lXm -lXt -lXext -lX11-lm
14.5 Java3D
HP 3D Technology for the Java Platform version 1.3 is available for both PA-RISC
and Itanium® platforms. 3D Technology for Java is a set of Java class libraries,
layered on top of OpenGL, that allows development of 3D graphics applications
in Java. HP 3D Technology for Java is a standard component of the Technical
Computing Operating Environment.
14.6 Resources
HP-UX Developer’s Toolkit:
http://www.software.hp.com/DTDC_products_list.html
HP-UX 11.00 Graphics Technical Computing Environment:
http://www.software.hp.com/ER_products_list.html
HP 3D Technology for Java:
http://www.hp.com/go/java
Graphics Issues
14–3
15
Networking
Networking is becoming more prevalent in application development. This chapter
discusses some of the more popular networking implementation processes and
procedures in use today, and how they apply to porting from Tru64 UNIX to HP-UX
11i.
15.1 SNMP Agents
The Simple Network Management Protocol (SNMP) is used to manage everything
from switches, to systems, to network appliances (storage arrays, dedicated
servers, and so on). Both Tru64 UNIX and HP-UX 11i provide an extensible SNMP
system based on the master-agent/subagent design model.
The Tru64 UNIX product includes both a SNMP system management facility and
the APIs, tools, and utilities needed to develop SNMP subagents (see Chapter 6 of
the Tru64 UNIX Network Programmer’s Guide).
The HP-UX 11i product includes the SNMP system management facilities needed
to manage the system, but does not include a SNMP development environment.
One of the first steps in porting SNMP subagent code from Tru64 UNIX to HP-UX
11i is to obtain a suitable SNMP development environment.
There are a number of good SNMP subagent development environment products
available to work with HP-UX 11i. One such product is the EMANATE Subagent
Development Kit (SADK) from SNMP Research. See the following URL for details:
http://www.snmp.com
Another option to consider before porting a Tru64 UNIX SNMP subagent to HP-UX
11i, is to determine if there is a lower cost solution. For example, the HP OpenView
Extensible SNMP Agent product offers a nonprogrammatic SNMP management
facility. This HP OpenView Extensible SNMP Agent product is currently only
available for HP-UX 11i v1. See the following URL for details:
http://www.openview.hp.com/products/snmp
15.2 Sockets
Sockets are the de facto industry standard interface for writing networking
applications. The sockets framework is BSD-based, consisting of a series of system
and library calls, header files, and data structures. Applications can access
kernel-resident networking protocols, such as the Internet Protocol suite, through
socket system calls. Applications can also use socket library calls to manipulate
network information; for example, mapping service names to service numbers
or translating the byte order of incoming data to that appropriate for the local
system’s architecture.
Both Tru64 UNIX and HP-UX 11i provide BSD4.3, UNIX 95 (XNS4.0), and
UNIX 98 (XNS5.0) socket interfaces. HP-UX 11i does not provide support for
BSD4.4 sockets. BSD4.4 sockets are enabled on Tru64 UNIX by the definition
of _SOCKADDR_LEN prior to the inclusion of any header files, often by using the
-D_SOCKADDR_LEN option on the compile line. If you are using BSD4.4 sockets,
take this opportunity to move to UNIX 98 (XNS5.0) networking. Though the
socket programming interfaces on the two operating systems are almost identical,
Networking
15–1
some differences do exist. The following sections discuss these implementation
differences. We concentrate on the features of Tru64 UNIX that are not available
on HP-UX 11i.
Table 15–1 provides a summary of the socket API comparison between Tru64
UNIX and HP-UX 11i.
Table 15–1: Summary of Socket API Comparison
API
Arguments
Return Values
errno Values
accept(2)
No Changea
No Change
See Section 15.2.1
No
Changea
No Change
See Section 15.2.2
No
Changea
No Change
See Section 15.2.3
listen(2)
No
Changea
No Change
See Section 15.2.4
getpeername(2)
No Changea
No Change
See Section 15.2.5
getsockname(2)
No Changea
No Change
See Section 15.2.6
getsockopt(2)
See Section 15.2.7
bind(2)
connect(2)
No Change
See Section 15.2.7
No
Changea
No Change
See Section 15.2.8
No
Changea
No Change
See Section 15.2.8
No
Changea
No Change
See Section 15.2.8
send(2)
No
Changea
No Change
See Section 15.2.9
sendto(2)
No Changea
No Change
See Section 15.2.10
sendmsg(2)
No Changea
No Change
See Section 15.2.10
setsockopt(2)
See Section 15.2.11
No Change
See Section 15.2.11
No Change
See Section 15.2.12
No Change
See Section 15.2.13
No Change
See Section 15.2.14
recv(2)
recvfrom(2)
recvmsg(2)
Changea
shutdown(2)
No
socket(2)
See Section 15.2.13
socketpair(2)
No
Changea
a BSD4.4 socket structures not supported.
The following sections detail the differences between the various APIs. Those APIs
with no differences are not discussed. The lack of support for BSD4.4 sockets is not
discussed as all socket APIs on HP-UX 11i have this restriction.
15.2.1 accept
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
EPROTO
A protocol error occurred.
The EAGAIN errno value used on HP-UX 11i to indicate no connections present in
nonblocking (O_NONBLOCK) networking is equivalent to EWOULDBLOCK on Tru64
UNIX.
15.2.2 bind
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
15–2
Networking
EIO
For an AF_UNIX socket, an I/O error occurred.
EISDIR
The address argument is a null pointer.
ELOOP
For an AF_UNIX socket, too many symbolic links were encountered
in translating the pathname in the address.
ENAMETOOLONG
A component of the pathname exceeded NAME_MAX characters, or
an entire pathname exceeded PATH_MAX characters.
ENOENT
For an AF_UNIX socket, a component of the pathname does not
name an existing file or the pathname is an empty string.
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
ENOTDIR
For an AF_UNIX socket, a component of the path prefix of the
pathname in the address is not a directory.
EROFS
For an AF_UNIX socket, the name would reside on a read-only
file system.
The ENOMEM HP-UX 11i errno value is not supported on Tru64 UNIX for bind.
15.2.3 connect
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
EACCES
Search permission is denied for a component of the path prefix,
or write access to the named socket is denied. This error applies
to AF_UNIX sockets only.
ECONNRESET
The remote host reset the connection request.
EHOSTUNREACH
The specified host is not reachable.
EIO
For an AF_UNIX socket, an I/O error occurred.
ELOOP
For an AF_UNIX socket, too many symbolic links were encountered
in translating the pathname in the address.
ENAMETOOLONG
A component of the pathname exceeded NAME_MAX characters, or
an entire pathname exceeded PATH_MAX characters.
ENOENT
For an AF_UNIX socket, a component of the pathname does not
name an existing file or the pathname is an empty string.
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
ENOTDIR
For an AF_UNIX socket, a component of the path prefix of the
pathname in the address is not a directory.
EPROTOTYPE
The specified address has a different type than the socket bound
to the specified peer address.
EWOULDBLOCK
The socket is marked nonblocking, so the connection cannot be
immediately completed. The application program can select the
socket for writing during the connection process.
The following is a list of errno values available on HP-UX 11i but not on Tru64
UNIX. These values may provide inexact mappings for other Tru64 UNIX values
not present on HP-UX 11i.
ENOSPC
All available virtual circuits are in use.
ENOMEM
No memory is available. The connect(3) has failed.
Networking
15–3
15.2.4 listen
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
EACCES
Search permission is denied for a component of the path prefix;
or write access to the named socket is denied. This error applies
to AF_UNIX sockets only.
ENOBUFS
Insufficient resources are available in the system to complete the
call.
15.2.5 getpeername
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
ENOSR
Insufficient resources were available in the system to complete
the call.
EOPNOTSUPP
The operation is not supported for the socket protocol.
15.2.6 getsockname
The ENOSR errno value used on Tru64 UNIX to indicate insufficient STREAMS
resources is not available on HP-UX 11i.
15.2.7 getsockopt
The SO_REUSEPORT and SO_USELOOPBACK options may have different behavior on
the two platforms. Tru64 UNIX provides several cluster-specific options. These
and several other unavailable options are listed here:
SO_CLUA_DEFAULT_SRC
In a cluster, reports whether the socket will use the default
cluster alias as its source address.
SO_CLUA_IN_NOALIAS
In a cluster, reports whether the socket can only receive
packets addressed to this cluster member.
SO_CLUA_IN_NOLOCAL
In a cluster, reports whether the socket must receive packets
addressed to a cluster alias and will drop any packets that
are not addressed to a cluster alias.
SO_RCVLOWAT
Reports the minimum number of bytes for socket receive
operations.
SO_RCVTIMEO
Reports receive timeout information.
SO_RESVPORT
In a cluster, reports whether an attempt to bind the socket
to a port in the reserved range will fail if the port is marked
static.
SO_REUSEALIASPORT
In a cluster, reports whether the socket can reuse a locked
cluster alias port.
SO_SNDLOWAT
Reports the minimum number of bytes for socket transmit
operations.
SO_SNDTIMEO
Reports send timeout information.
HP-UX 11i provides an additional option for sockets:
SO_REUSEPORT
15–4
Networking
If enabled, allows a local address and port to be reused in
subsequent calls to bind(3).
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
EACCES
The calling process does not have appropriate permissions.
EDOM
The send and receive timeout values are too large to fit in the
timeout fields of the socket structure.
ENOSR
Insufficient resources were available in the system to complete
the call.
15.2.8 recv, recvfrom, recvmsg
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
EACCES
The calling process does not have appropriate permissions.
EIO
An I/O error occurred while reading from or writing to the file
system.
ENOMEM
The system did not have sufficient memory to fulfill the request.
The following is a list of errno values available on HP-UX 11i but not Tru64 UNIX.
These values may provide inexact mappings for other Tru64 UNIX values not
present on HP-UX 11i.
EAGAIN
Nonblocking I/O is enabled using O_NONBLOCK flag with
fcntl(3) and the receive operation would block, or the socket
has an error that was set asynchronously.
EMFILE
The number of file descriptors available to the calling process
has been exceeded.
15.2.9 send
Both platforms conform to the UNIX 95 and UNIX 98 standards. For backward
compatibility, both platforms allow the third parameter to be an integer. HP-UX
11i does not support the MSG_DONTROUTE option, which is used in Tru64 UNIX
for debugging purposes only.
The ENOSR errno value used on Tru64 UNIX to indicate insufficient STREAMS
resources are not available on HP-UX 11i.
The following is a list of errno values available on HP-UX 11i but not Tru64 UNIX.
These values may provide inexact mappings for other Tru64 UNIX values not
present on HP-UX 11i.
EAFNOSUPPORT
EAGAIN
The specified address is not a valid address for the address family
of this socket.
Nonblocking I/O is enabled using the O_NONBLOCK flag with
fcntl(3), and the requested operation would block, or the socket
has an error that was set asynchronously.
15.2.10 sendto, sendmsg
Both platforms conform to the UNIX 95 and UNIX 98 standards. For backward
compatibility, both platforms allow the third and sixth parameters to be integers.
HP-UX 11i does not support the MSG_EOR and MSG_DONTROUTE options.
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
Networking
15–5
ELOOP
Too many symbolic links were encountered in translating the
pathname in the socket address.
ENAMETOOLONG
For AF_UNIX sockets, a component of the pathname exceeded
NAME_MAX characters, or an entire pathname exceeded PATH_MAX
characters.
ENOENT
A component of the pathname does not name an existing file or
the pathname is an empty string.
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
ENOTDIR
A component of the path prefix of the pathname in the address
is not a directory.
The EAGAIN errno value used on HP-UX 11i to indicate nonblocking I/O is enabled
(O_NONBLOCK) is equivalent to EWOULDBLOCK on Tru64 UNIX.
15.2.11 setsockopt
The SO_REUSEPORT and SO_USELOOPBACK options may have different behavior on
the two platforms. Tru64 UNIX provides several cluster-specific options. These
and several other unavailable options as follows:
SO_CLUA_DEFAULT_SRC
In a cluster, specifies that if the local address has not
already been set through a call to bind(3), the socket will
use the default cluster alias as its source address.
SO_CLUA_IN_NOALIAS
In a cluster, specifies that the socket can only receive
packets addressed to this cluster member.
SO_CLUA_IN_NOLOCAL
In a cluster, specifies that the socket must receive packets
addressed to a cluster alias and will drop any packets that
are not addressed to a cluster alias.
SO_RCVLOWAT
Reports the minimum number of bytes for socket receive
operations.
SO_RCVTIMEO
Sets receive time out.
SO_RESVPORT
In a cluster, an attempt to bind the socket to a port in the
reserved range will fail if the port is marked static.
SO_REUSEALIASPORT
In a cluster, specifies that the socket can reuse a locked
cluster alias port.
SO_SNDLOWAT
Sets the minimum number of bytes for socket transmit
operations.
SO_SNDTIMEO
Sets send time out.
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
EACCES
The calling process does not have appropriate permissions.
EDOM
The send and receive timeout values are too large to fit in the
timeout fields of the socket structure.
EISCONN
The socket is already connected; the specified option cannot be set
when the socket is in the connected state.
ENOMEM
The system did not have sufficient memory to fulfill the request.
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
The following errno value is available on HP-UX 11i but not Tru64 UNIX. This
value may provide inexact mappings for other Tru64 UNIX values not present
on HP-UX 11i.
15–6
Networking
EOPNOTSUPP
The option is not supported by the socket family or socket type.
15.2.12 shutdown
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
ENOBUFS
Insufficient resources are available in the system to complete
the call.
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
15.2.13 socket
The Tru64 UNIX SOCK_RAW option is not available in HP-UX 11i. Support for
the X25 standard, not available on Tru64 UNIX, is available on HP-UX 11i by
including the x25/x25ccittproto.h header file. The X25 standard adds support
for AF_VME_LINK and AF_CCITT options to socket(3).
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
EACCES
The process does not have appropriate privileges.
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
EPERM
The process is attempting to open a raw socket and does not have
the superuser privilege.
The following is a list of errno values available on HP-UX 11i but not Tru64 UNIX.
These values may provide inexact mappings for other Tru64 UNIX values not
present on HP-UX 11i.
EHOSTDOWN
The networking subsystem is not up.
EINVAL
SOCK_DGRAM sockets are currently not supported for the AF_UNIX
or AF_VME_LINK address families.
ESOCKTNOSUPPORT
The specified socket type is not supported in this address family.
ETIMEDOUT
Connection timed out.
15.2.14 socketpair
The following is a list of errno values available for Tru64 UNIX but not on HP-UX
11i:
EACCES
The process does not have appropriate privileges.
ENOMEM
The system was unable to allocate kernel memory to increase the
process descriptor table.
ENOSR
The available STREAMS resources were insufficient for the
operation to complete.
EPROTOTYPE
The socket type is not supported by the protocol.
15.3 STREAMS
The STREAMS framework provides an alternative to sockets. The STREAMS
interface was developed by AT&T and consists of system calls, kernel routines, and
kernel utilities that are used to implement everything from networking protocol
Networking
15–7
suites to device drivers. Applications in user space access the kernel portions of the
STREAMS framework using standard system calls.
STREAMS APIs are similar but, due to implementation details, differences do
exist. The following sections discuss these implementation differences. We
concentrate on the features of Tru64 UNIX that are not available or not supported
on HP-UX 11i. Table 15–2 provides a summary comparing the STREAMS APIs.
Table 15–2: Summary of STREAMS API Comparison
API
Arguments
Return Values
errno Values
close(2)
No Change
No Change
No Change
getmsg(2)
No Change
No Change
See Section 15.3.1
getpmsg(2)
No Change
No Change
See Section 15.3.1
ioctl(2)
See Section 15.3.5
See Section 15.3.5
See Section 15.3.5
pread(2)
No Change
No Change
No Change
putmsg(2)
No Change
See Section 15.3.3
See Section 15.3.3
putpmsg(2)
No Change
See Section 15.3.3
See Section 15.3.3
pwrite(2)
No Change
No Change
No Change
open(2)
See Section 15.3.2
No Change
See Section 15.3.2
read(2)
No Change
No Change
No Change
readv(2)
No Change
No Change
No Change
select(2)
No Change
No Change
See Section 15.3.4
streamio(2)
See Section 15.3.5
See Section 15.3.5
See Section 15.3.5
strmod_add(2)
Not Available
Not Available
Not Available
strmod_del(2)
Not Available
Not Available
Not Available
write(2)
No Change
No Change
No Change
writev(2)
No Change
No Change
No Change
15.3.1 getmsg, getpmsg
Receives the next message from a STREAM.
The system errno value EFAULT is not supported in HP-UX 11i.
15.3.2 open
Opens a STREAM for reading or writing.
HP-UX 11i does not need to include sys/stat.h and sys/types.h files.
The STREAM-related error number ENOSR is not supported in HP-UX 11i.
15.3.3 putmsg, putpmsg
Send a message on a STREAM.
The system errno values EFAULT and EBADMSG are not supported in HP-UX 11i.
15.3.4 select
The system errno value EAGAIN is not supported in HP-UX 11i.
15–8
Networking
15.3.5 streamio, ioctl
The commands in Tru64 UNIX conform to XSH4.2. The STREAMSioctl(2)
function on both platforms refer to a wide range of commands, options, and error
numbers. See the reference pages for details.
15.4 Other Network Differences
HP-UX 11i does not support DECnet or LAT (Local Area Transport). DLPI (Data
Link Provider Interface) is supported on HP-UX 11i v2. Also, the ifconfig
network utility command on HP-UX 11i has no -a option. You must provide an
interface name after entering the command. HP-UX 11i has a network utility
command, lanscan, that displays LAN device configuration and status. Another
useful tool is lanadmin(1). See the reference pages for more information.
If an interface’s MAC address is used in Tru64 UNIX to identify a unique machine,
you can use HP-UX 11i’s library function confstr(3C) for this purpose. For
example:
#include <unistd.h>
#include <stddef.h>
size_t bufsize;
char *buffer;
bufsize=confstr(_CS_MACHINE_IDENT,NULL,(size_t)0);
buffer=(char *)malloc(bufsize+1);
confstr(_CS_MACHINE_IDENT,buffer,bufsize+1);
See the HP-UX 11i Release Notes or reference pages for more information.
15.5 References
For more information on STREAMS and sockets, see:
•
Tru64 UNIX and HP-UX 11i reference pages.
•
Tru64 UNIX Network Programmer’s Guide
Tru64 UNIX Programmer’s Guide, Section 1.6 IPC:
http://www.hp.com/go/tru64docs
•
HP-UX 11i online documents:
http://docs.hp.com/hpux/11i/index.html
Networking
15–9
16
Security
This chapter describes the differences between the system-level security facilities
available on Tru64 UNIX and HP-UX 11i.
16.1 Moving from SIA on Tru64 UNIX to PAM on HP-UX 11i
This section presents the differences between the Tru64 UNIX Security Integration
Architecture (SIA) and the HP-UX 11i Pluggable Authentication Modules (PAM)
facilities with respect to functionality and APIs.
Both Tru64 UNIX and HP-UX 11i provide framework facilities for layering local
and network security methods on a systemwide basis. These security methods are
implemented in libraries of routines that can be plugged into the host system.
These frameworks isolate the security-sensitive commands such as login(1)
from the actual security method implementations, and allow layering of new
security methods on top of the default system security methods, such as the use
of /etc/passwd information.
To describe the similarities and differences between the Tru64 UNIX SIA and the
HP-UX 11i PAM facilities, brief overviews of both facilities are presented before
they are compared.
16.1.1 Tru64 UNIX SIA Overview
Tru64 UNIX Security Integration Architecture (SIA) APIs provide the following
security services:
•
Identification
•
Authentication
•
Authorization
The architecture is split into application or utility APIs (the sia_*(3) functions)
and security mechanism provider APIs (the siad_*(3) functions). Applications and
utilities do not deal with the specifics of how an entity (user or application) gets
identified, authenticated, and authorized, just the proper process and order of
calls. A small set of SIA API users supply security mechanism implementations.
These security mechanism providers create libraries of routines that define
and implement the required plug-in APIs. The system administrator uses the
siacfg(8) tool to add and remove SIA mechanisms. The matrix.conf(4) file
defines the order in which mechanisms are loaded and called by the applications
on a systemwide basis.
Application APIs
Applications and utilities will call sia_*(3) routines, which in turn will call
each configured plug-in mechanism at its corresponding siad_*(3) interface,
as long as the preceding mechanism did not request the processing to be
stopped. For example, a call to sia_ses_authent(3) will result in calls to each
siad_ses_authent(3) routine library listed in the matrix.conf(4) file. As
long as the siad_ses_authent(3) routine does not return a stop flag, the next
mechanism interface gets called, regardless of whether or not the preceding
mechanism implementation failed or succeeded.
Security
16–1
Security Mechanism Provider APIs
SIA security mechanism implementations require that all of the siad_*(3) routines
be defined and minimally provide an implementation that returns a failure code.
They can then provide more functional implementations for all or some of the
following three service functions:
•
Session processing: APIs handle all authentication of entities to the
system. There are seven mandatory session processing routines that must be
implemented if any session processing plug-in is to be provided:
siad_ses_init(3)
siad_ses_authent(3)
siad_ses_suauthent(3)
siad_ses_reauthent(3)
siad_ses_estab(3)
siad_ses_launch(3)
siad_ses_release(3)
Utilities such as login(1), ftp(1), telnet(1), su(1), the r*(1) remote commands,
and the dt*(1), and the dx*(1) commands will make sia_ses_*(3) calls in
order to identify and authenticate an entity to the system.
•
Change processing: Handles all requests to change security-related
information. There are five mandatory change processing routines that must
be implemented if any session processing plug-in is to be provided:
sia_chg_finger(3)
sia_chg_password(3)
sia_chg_shell(3)
sia_chk_user(3)
sia_chk_invoker(3)
Utilities such as passwd(1), chfn(1), and chsh(1) are implemented using the
sia_chg_*(1) interfaces.
•
Data processing: Handles all requests to get group and password data. There
are ten mandatory data processing routines that must be implemented if any
session processing plug-in is to be provided:
siad_getpwent(3)
siad_getpwuid(3)
siad_getpwnam(3)
siad_setpwent(3)
siad_endpwent(3)
siad_getgrent(3)
siad_getgrgid(3)
siad_getgrnam(3)
siad_setgrent(3)
siad_endgrent(3)
The Tru64 UNIX SIA data processing service functionality is not available
in the HP-UX 11i PAM security service. Instead, use the HP-UX 11i Name
Service Switch (NSS) services.
The status of the previous call may be passed to the mechanism to allow it to
decide whether or not to accept the preceding mechanism’s view. This is especially
important during authentication where subsequent mechanisms may want to allow
a previous mechanism to vouch for a successfully authenticated credential, rather
than prompt for the username and password again.
16.1.2 HP-UX 11i PAM Overview
HP-UX 11i Pluggable Authentication Modules (PAM) provide a set of APIs to
perform security service processing based on the following set of security service
module types:
•
16–2
Authentication
Security
•
Account management
•
Session
• Password
The architecture is split into application and utility APIs (the pam_*(3) functions)
and service module APIs (the pam_sm_*(3) functions). Like SIA, PAM applications
and utilities do not deal with the particulars of how a user or application (entity)
would be authenticated, just the proper process and order of calls. If a service
request is successful, the application or utility then calls the various pam_*(3)
functions. Service module providers create libraries that contain any of the six
functions defined to support the service module types. Module providers may
define as few as one or all six entry points. Security services are mostly predefined
by the architecture as a list of common authentication utilities, such as login(1),
ftp(1), telnet(1), su(1), rlogin(1), passwd(1), and so forth. There is also an
other service defined that may be utilized in the event that an application or
utility does not request a known security service.
The PAM architecture requires the system administrator to define PAM services
for each of the service module types. Specifically, the system administrator will
define each available service, the module type, calling rules, and the order in which
to call the library(ies) specified in the pam.conf(4) configuration file. The call to
each service module API is made based on the status of the previous call, a control
flag, module options, and order listed in the pam.conf(4) file.
This calling sequence is known in PAM parlance as stacking. The stacking feature
allows an administrator to define which modules are required, requisite, optional,
or sufficient for each service. The pam_*(3) interfaces use this configuration
information to determine whether or not to continue the calling sequence based
on the behavior of previous calls. The module options are module-specific and are
listed in the pam.conf(4) file.
Applications or utilities will call the pam_*(3) routines, which in turn will call
each module library configured for the requested service based upon the stacking
rules. For example, if a call to pam_start(3) requests the login service, the call
to pam_authenticate(3) will result in calls to libraries with the corresponding
pam_authenticate(3) from the list of authentication module types. Depending
on the return value of the first call and the value of its control flag, PAM will
determine whether or not the next module in the stack gets called.
16.1.3 Differences Between SIA and PAM
SIA has system-level security as its main design focus. The SIA model enforces a
security policy for all users and applications, and does not require applications to
perform authorization functions. Under SIA, the security mechanism providers
bear the brunt of providing the functionality for the desired policy.
In general, SIA requires mechanism providers to provide more complete solutions
rather than unique features to existing solutions.
SIA provides a local security mechanism that handles some authorization
functions. After each mechanism’s siad_ses_estab(3) interface is called by the
application’s call to sia_ses_estab(3), SIA may perform the following operations:
•
Set the login UID using setluid(3)
•
Check user account disk quotas
•
Check for proper licenses
• Display the last login information
These operations can be duplicated by some PAM account management modules.
In addition, after each SIA security mechanism’s siad_ses_launch(3) interface is
Security
16–3
called by the application’s sia_ses_launch(3) call, SIA will call the local security
mechanism to perform the authorization calls that PAM requires each application
to call. The processing performed by SIA during this local mechanism call may
include the following operations:
•
setlogin(2)
•
setgid(2)
•
initgroups(3)
•
Update utmp(4) and wtmp(4)
•
Set terminal ownership and characteristics
•
seteuid(3)
•
Change the directory to the user’s home directory specified in the passwd(4)
profile
Some of these functions may be provided by PAM account and session modules.
You can create an other service library that defines the callbacks for PAM
authentication management and session management to perform these calls.
A typical application or utility that uses the PAM login service will initially call
pam_start(3) to initiate an authentication transaction. The application will next
call pam_authenticate(3), which will cause PAM to call the libraries listed
in the pam.conf(4) file for the login service and auth module type at their
pam_sm_authenticate(3) entry point. Depending on the control flag and status of
the return, the next library’s pam_sm_authenticate(3) implementation may be
called. The application may then decide to call the pam_acct_mgmt(3) interface or
the pam_open_session(3) interface. For pam_acct_mgmt(3), each of the login
service’s account module type entries could be called. For pam_open_session(3),
each of the session module type entries for the login service could be called. The
pam_end(3) routine terminates the authentication transaction.
SIA requires that mechanisms supporting change processing also support session
processing. This forces the mechanism to identify and authenticate that the user
requesting the change is authorized to make the change. PAM does not impose
this requirement.
PAM is service-oriented and provides the system administrator with more flexibility
to determine the authentication rules on the system. The PAM model relies on
the system administrator correctly configuring the security environment for the
system. The stacking and calling principles require the system administrator to
have knowledge and trust of each of the modules in the stacking chain.
PAM provides the capability to break down the authentication and session
processing into much smaller units than SIA. PAM has the flexibility to add
functionality by providing PAM modules that perform a single function. For
example, a PAM mechanism may be created and configured to determine if a
specific user may have access to a specific system between specific times. That
mechanism could then be placed under the account module type using the other
service and be required to run.
16.1.4 PAM Data Processing Capabilities
How does PAM make up for the lack of data processing capabilities that SIA has?
The PAM architecture does not provide a means to plug in modules that provide
group and password data. Rather, PAM implementations rely on either static
/etc/passwd and /etc/group files or some sort of Network Security Services
(NSS) to retrieve user or application identification criteria.
In general terms, NSS allows the system administrator to define the path (other
than /etc/) for a known set of system data services, such as password, group,
16–4
Security
hosts, and others. Instead of statically looking in /etc/ for a file, the NSS interface
routines are called to reference configured libraries to call lookup routines that
either reference data files locally or a network interface.
16.1.5 API Comparison — SIA and PAM Similarities
Table 16–1 compares some similar SIA and PAM interfaces used by applications
and utilities.
Table 16–1: SIA and PAM Application API Similarities
SIA
PAM
sia_init(3)
sia_ses_init(3)
pam_start(3)
sia_ses_authent(3)
sia_ses_suauthent(3)
pam_authenticate(3)
sia_ses_reauthent(3)
pam_chauthtok(3)
sia_ses_estab(3)
pam_acct_mgmt(3)
sia_ses_launch(3)
pam_open_session(3)
pam_setcred(3)
sia_ses_release(3)
pam_close_session(3)
pam_end(3)
The remainder of this section provides additional information and comparisons
between the SIA and PAM application APIs.
sia_ses_init(3), sia_init(3)
The sia_init(3) function will read the matrix.conf(4) file. This routine
is generally only called internally by SIA, but it may be called directly by
applications. The sia_ses_init(3) interface returns an SIA entity much like the
pam_start(3) returns a PAM handle. The entity is a public structure that can be
filled in by the caller. The PAM handle is filled in by using the pam_set_item(3),
pam_set_data(3), and pam_putenv() interfaces.
sia_ses_authent(3), sia_ses_suauthent(3)
These routines will perform the prompts for username and password unless
already set in the entity. The PAM architecture defines a means for a user to define
a conversion routine. SIA has the application pass a pointer to a routine or it
defaults to its own interface using sia_collect_trm(3).
sia_ses_reauthent(3)
This routine is used primarily to determine whether or not the user still knows
their password. It will take the login name as originally set and may prompt the
user for a password.
sia_ses_estab(3)
This routine handles all the user account checks with respect to whether the user
has the rights to access the system at this time.
sia_ses_launch(3)
This routine will set up the final user environment. This includes setting the user
authorizations and changing the user’s effective ID.
sia_ses_release(3)
This routine is called just prior to the application creating the user session. This
could include:
Security
16–5
•
Invoking the user’s shell
•
Creating a file
•
Or any other process requiring security validation
16.1.6 API Comparison — SIA and PAM Mechanism Similarities
Table 16–2 compares some similar SIA and PAM interfaces used by security
mechanism providers.
Table 16–2: SIA and PAM Mechanism API Similarities
SIA
PAM
siad_ses_init(3)
Not applicable
siad_ses_authent(3)
siad_ses_suauthent(3)
pam_sm_authenticate(3)
siad_ses_reauthent(3)
pam_sm_chauthtok(3)
siad_ses_estab(3)
pam_sm_acct_mgmt(3)
siad_ses_launch(3)
pam_sm_open_session(3)
pam_sm_setcred(3)
siad_ses_release(3)
pam_sm_close_session(3)
pam_end(3)
The remainder of this section provides additional information and comparisons
between the SIA and PAM security mechanism implementation support APIs.
siad_ses_init(3)
This routine is called to allow each security mechanism implementation to set
up implementation-specific storage and allocate any resources required. This
information is stored within the entity structure that is passed by the application
to each of the remaining siad_ses_*(3) calls.
siad_ses_authent(3), siad_ses_suauthent(3)
The siad_ses_authent(3) and siad_ses_suauthent(3) routines determine if
the security mechanism actually recognizes (knows) the user listed in the entity,
and if the password provided by the user matches their account database record.
The rules for matching may be specific to each security mechanism implementation.
siad_ses_reauthent(3)
This routine will perform many of the same operations as the siad_ses_authent(3)
and siad_ses_suauthent(3) routines. The difference is that this function is not
used by the applications to become another user.
siad_ses_estab(3)
Most SIA mechanisms do not have any specific session establishment calls to make.
They simply return SIADFAIL and rely on the local security mechanism to perform
its checks. Implementations could determine if an account is locked out, if the user
is allowed to access the system given some time contraints, if the user has an
expired password, and so on.
siad_ses_launch(3)
Most SIA security mechanism implementations do not have any specific session
launch calls to make. They return SIADFAIL and rely on the local mechanism to
perform its checks. Implementations could handle setting up the proper operating
environment, such as setting specific tty permissions, logging success or fail,
setting privileges for user accesses, setting auditing capabilities, and so forth.
16–6
Security
siad_ses_release(3)
This routine releases all memory and resources allocated by the siad_ses_init(3)
call.
16.1.7 API Comparison — APIs That Are Unique to PAM
Table 16–3 lists PAM interfaces that do not map well to SIA routines.
Table 16–3: PAM APIs that do not have SIA equivalents
PAM
Comments
pam_set_item(3)
pam_get_item(3)
pam_get_user(3)
These routines allow access and changes to specific fields
contained within the opaque PAM handle data structure.
pam_sterror(3)
This routine converts a PAM error code into a string.
pam_set_data(3)
pam_get_data(3)
pam_end(3) will clean up any memory if necessary. SIA
pam_putenv(3)
pam_getenv(3)
pam_getenvlist(3)
These routines allow modules to share data by name.
provides the ability for each mechanism to create and store
entity mechanism-specific data. The SIA model does not
require mechanism-specific data to be shared, but it is not
required or enforced that this data be private.
These routines allow access and changes to PAM-specific
environment variables, much like their libc-related routines.
These environment variables are specific to each PAM handle
and are structured as name/value pairs. The main difference
between pam_putenv(3) and its libc equivalent is that the
PAM routine deletes a PAM environment variable if the value
is the same as the environment variable’s name.
Security
16–7
17
Internationalization Support
This chapter discusses internationalization (also known as I18N) support for Tru64
UNIX and HP-UX 11i. This chapter also refers to localization (also known as
L10N), Curses, and X/Xt/Motif APIs. For more information, see the Migrating
Internationalized Applications from Tru64 UNIX to HP-UX white paper:
http://devrsrc1.external.hp.com/STKT/portguides.html
Current Tru64 UNIX I18N support conforms to the X/Open CAE specifications
of the XSH 5.0 standard. HP-UX 11i support conforms to the X/Open CAE
specifications of the XSH 4.0 and POSIX 1003.1 (which is the same as SVID 3)
standards. Later versions of HP-UX 11i added more features.
A new set of multibyte APIs have been added to the HP-UX 11i libc following the
C99 specification (ISO/IEC 9899:1999) and the UNIX 98 specification. See the
HP-UX 11i Release Notes for more information.
17.1 Encoding Methods
Tru64 UNIX Version 5.1A supports Unicode Version 3.0. Note that Tru64 UNIX
Version 5.1B supports Unicode Version 3.1. This is significant because Unicode
Version 3.1 contains about 94,000 characters, as compared to Version 3.0, which
contains approximately 49,000 characters and Version 2.1, which contains almost
39,000 characters. HP-UX 11i v2 supports Unicode Version 3.0. Earlier HP-UX 11i
versions support Version 2.1. Unicode provides three encoding forms:
•
UTF-8, a multibyte-compatible encoding, which does not have any endian issues
•
UTF-16 (also sometimes called UCS-2) in which code units are 16 bits each
•
UTF-32 (sometimes called UCS-4) in which code units are 32 bits each
UTF-16 and UTF-32 data on Tru64 UNIX and HP-UX 11i is processed differently
because of the endian differences between the two platforms (see Chapter 12 for
more information on endian considerations). In general, data is in one of these
forms for both platforms during internal processing only, and is not stored to disk.
Rather, it is stored to disk in UTF-8 form. This means that you can exchange
UTF-8 data between the two platforms without endian problems.
The X/Open UNIX standard does not require an operating system to supply any
particular codesets in addition to ASCII. The standard does specify requirements
for the interfaces that manipulate characters so that programs can handle
characters from whatever codeset is available on a given system. Both Tru64 UNIX
and HP-UX 11i provide commands and APIs for such manipulation.
Table 17–1 lists the supported codesets and encoding methods on Tru64 UNIX and
their compatible codesets and encoding methods on HP-UX 11i, if available.
Table 17–1: Table 17–1: Encoding Methods
Tru64 UNIX
HP-UX 11i
ISO 8859-1 (Latin-1)
ISO 8859-1 (Latin-1)
ISO 8859-2 (Latin-2)
ISO 8859-2 (Latin-2)
ISO 8859-3 (Latin-3)
Not Available
Internationalization Support
17–1
Table 17–1: Table 17–1: Encoding Methods (cont.)
Tru64 UNIX
HP-UX 11i
ISO 8859-4 (Latin-4)
Not Available
ISO 8859-5 (Latin-Cyrillic)
ISO 8859-5 (Latin-Cyrillic)
ISO 8859-7 (Latin-Greek)
ISO 8859-7 (Latin-Greek)
ISO 8859-8 (Latin-Hebrew)
ISO 8859-8 (Latin-Hebrew)
ISO 8859-9 (Latin-Turkish) (Also known as
Latin-5)
ISO 8859-9 (Latin-Turkish) (Also known as
Latin-5)
ISO 8859-15 (Latin-9)
ISO 8859-15 (Latin-9)
Japanese Extended UNIX Code
Japanese Extended UNIX Code
Shift JIS
Shift JIS
DEC Kanji
Not Available
Super DEC Kanji
Not Available
DEC Korean
Not Available
Korean Extended UNIX Code
Korean Extended UNIX Code
Thai API Consortium/Thai Industrial
Standard
Thai API Consortium/Thai Industrial
Standard
DEC Hanzi
Not Available
DEC Hanyu
Not Available
Taiwanese Extended UNIX Code
Taiwanese Extended UNIX Code
Big-5
Big-5
GBK
GBK
GB18030-2000
GB18030-2000
17.2 Input Methods
In addition to common European language input methods, both Tru64 UNIX and
HP-UX 11i support varieties of input methods for Asian languages. The following
sections discuss Tru64 UNIX input methods and their equivalents on HP-UX 11i, if
available.
The Tru64 UNIX operating system also supports the X Input and Output Methods
(XIM and XOM), with functions implemented according to the X11R6 specification.
Tru64 UNIX and HP-UX 11i include support for Japanese, simplified Chinese,
traditional Chinese, and Korean. There are third-party products that support other
input methods on both Tru64 UNIX and HP-UX 11i.
17.2.1 Japanese Input
Tru64 UNIX uses the dxjim input server to input Japanese. HP-UX 11i uses
the xjim input server. HP-UX 11i v2 also provides ATOK X to input Japanese.
Table 17–2 compares the Japanese input support for these input servers.
Table 17–2: Japanese Input Support Comparison
17–2
dxjim
xjim
ATOK X
Kana-to-Kanji
Kana-to-Kanji
Kana-to-Kanji
Romaji-to-Kanji
Romaji-to-Kanji
Romaji-to-Kanji
Internationalization Support
Table 17–2: Japanese Input Support Comparison (cont.)
dxjim
xjim
ATOK X
Code (deckanji/kuten)
Code
(euc/sjis/jis/kuten)
Code
(euc/sjis/jis/kuten)
Various symbol (non-Kanji)
Various symbol (non-Kanji)
Various symbol (non-Kanji)
User dictionary
User dictionary
User dictionary
Not Available
Not Available
radical
Not Available
Not Available
number of stroke
Not Available
Not Available
code table
(euc/sjis/kuten/ucs2)
Not Available
Not Available
zip code dictionary
17.2.2 Simplified Chinese
Tru64 UNIX uses the dxhanziim input server to input simplified Chinese; HP-UX
11i uses the xsim input server.
Table 17–3: Simplified Chinese Input Support Comparison
dxhanziim
xsim
5-stroke
5 stroke-zxa, 5 stroke-ha
5-Shape
Not Available
Pin-Yin (aka Phonetic)
Pinyin
Qu-Wei (aka Row-Column in GB2312-80)
Section/Position
Telex Code
Not Available
Phrase Input
Not Available
Intelligent ABC
Intelligent ABC, available on HP-UX 11i v2
and higher
Not Available
Full size ASCII
Not Available
HP 15 Code
Not Available
Tsang-Chieh, Not Available from HP-UX 11i
v2 and higher
Not Available
Rapid Tsang-Chieh, Not Available from
HP-UX 11i v2 and higher
a Input methods may contain small differences, see the References section for more information.
17.2.3 Traditional Chinese
Tru64 UNIX uses dxhanyuim to input traditional Chinese; HP-UX 11i uses xtim.
Table 17–4: Traditional Chinese Input Support Comparison
dxhanyuim
xtim
Internal code
Not Available
Phonetic
Phonetic
Phrase
Not Available
Quick Tsang-Chi
Rapid Tsang-Chieh
Symbol
Not Available
Tsang-Chi
Tsang-Chieh
Internationalization Support
17–3
Table 17–4: Traditional Chinese Input Support Comparison (cont.)
dxhanyuim
xtim
Not Available
Full Size ASCII Input Mode
Not Available
CNS EUC
Not Available
Tele-1
Not Available
Tele-2
Not Available
CNS Interchange Code
Not Available
(Big5) Code
17.2.4 Korean
Tru64 UNIX uses dxhangulim to input Korean; HP-UX 11i uses xkim.
Table 17–5: Korean Input Support Comparison
dxhangulim
xkim
Hangul
Hangul
Hanja
HanJa
Row-Column Code
Code Inputa
Phrase Input Method
Not Available
Not Available
Full Size ASCII
a Input methods may contain small differences; see the References section for more information.
17.3 Codeset Converters
Both Tru64 UNIX and HP-UX 11i support a wide range of codeset converters.
See the /usr/lib/nls/loc/iconv/ and /usr/lib/nls/loc/iconvTable/
directories for a list of the converters installed on a Tru64 UNIX system. On
HP-UX 11i systems, the /usr/lib/nls/iconv/config.iconv file lists
the available converters and their aliases. The actual converters are under
/usr/lib/nls/iconv/tables and /usr/lib/nls/iconv/methods. See the
iconv reference pages for more information about codeset converters on both
platforms.
Tru64 UNIX provides a set of codeset converters for Unicode forms. The converters
that are endian-related include:
UTF-16, little endian
UTF-16BE, big endian
UTF-16LE, little endian
UTF-32, little endian
UTF-32BE, big endian
UTF-32LE, little endian
iconv converts data from a named input encoding to a named output encoding, so
these names here can either be input or output. By default, the plain UTF-16 and
UTF-32 converters assume little endian on input and produce little-endian output,
while the others assume/produce the designated I/O (for example, UTF-16BE is
for big-endian input or produces big-endian output). Make sure your output is big
endian if you want to transfer it to HP-UX 11i systems.
17.4 Locales
Individual languages and countries have varying requirements for the way data
should be processed or presented. Internationalized systems such as Tru64 UNIX
and HP-UX 11i define locales that hold collections of rules and data specific to a
17–4
Internationalization Support
language, region, and codeset or encoding method. Users can choose the locale that
meets their cultural and linguistic needs.
In many cases, there are multiple locales for a single language. For example, Tru64
UNIX provides seven Japanese locales, while HP-UX 11i provides four. Appendix E
lists the names of all the supported locales for Tru64 UNIX and their compatible
names on HP-UX 11i.
17.5 Message Catalogs
Part of an internationalized system is the ability to provide program text to users
in the languages of their choice. Tru64 UNIX and HP-UX 11i include messaging
systems that make it possible to separate program text from source code so that
text can be translated into multiple languages. The collection of program text from
a given program is called a message catalog.
Both Tru64 UNIX and HP-UX 11i provide standard common interfaces and
commands to create and access message catalogs. Note that three commands,
mkcatdefs(1), dspcat(1) and dspmsg(1), originally not available on HP-UX 11i,
are now ported to it. See the Tru64 UNIX Migration Environment for HP-UX
(http://www.hp.com/go/tru64appmigration) for more information.
17.6 APIs for Curses Applications
Tru64 UNIX has enhancements made to the Curses library to support
wide-character format, which accommodates multibyte characters. The
recommended functions to handle multibyte characters in wide-character or
complex-character format conform to Version 4.2 of the X/Open Curses CAE
specification and supersede those specified by the System V Multi-National
Language Supplement (MNLS).
The Curses library provides functions for developing user interfaces on
character-cell terminals. Tru64 UNIX Curses APIs support the following
standards:
•
Version 4.2 of the X/Open Curses CAE specification
•
Version 3 of the X/Open Curses CAE specification
•
System V Multi-National Language Standard (MNLS) APIs, which are Curses
library extensions for handling multibyte characters
•
BSD Curses APIs
•
Minicurses APIs
HP-UX 11i supports Version 4.0 of the X/Open Curses CAE specification
(X/Open Curses, Issue 4). For HP-UX 11i, applications should ensure that the
_XOPEN_SOURCE feature test macro is defined before the inclusion of any header.
This is needed to enable standard functionality, and possibly to enable functionality
defined elsewhere in the Common Applications Environment. On HP-UX 11i,
an application that uses any API specified as ENHANCED CURSES must define
_XOPEN_SOURCE_EXTENDED=1 in each source file or as part of its compilation
environment. When _XOPEN_SOURCE_EXTENDED=1 is defined in a source file, it
must appear before any header is included. See curses_intro(3X) of the HP-UX
11i reference pages for more information.
17.7 X/Xt/Motif Applications
X and Motif applications, which include a graphical user interface (GUI), usually
access X resource files, rather than message catalogs, for the small segments of text
that belong to the title bars, menus, buttons, and simple messages for a particular
Internationalization Support
17–5
window. Motif applications can also use a User Interface Language (UIL) file, along
with a text library file, to access help, error messages, and other kinds of text.
However, both X and Motif applications can access text in message catalogs as well.
The Tru64 UNIX X Window System supported version is Version 11 Release 6.3; the
HP-UX 11i supported version is Release 6.2. Tru64 UNIX Motif is 1.2 (2.1 is also
available); HP-UX 11i Motif is 2.1. See the related references for more information.
17.8 References
•
Migrating Internationalized Applications from Tru64 UNIX to HP-UX
http://devrsrc1.external.hp.com/STKT/portguides.html
•
Tru64 UNIX Writing Software for the International Market:
http://h30097.www3.hp.com/docs/base_doc/
DOCUMENTATION/V51B_HTML/ARH9YCTE/TITLE.HTM
•
Tru64 UNIX reference pages i18n_intro(5) and l10n_intro(5)
•
Tru64 UNIX Common Desktop Environment: Internationalization
Programmer’s Guide:
http://h30097.www3.hp.com/docs/base_doc/
DOCUMENTATION/V51B_HTML/COSEPRGD/TITLE.HTM
•
Tru64 UNIX Technical Reference for Using Chinese Features:
http://h30097.www3.hp.com/docs/base_doc/
DOCUMENTATION/V51B_HTML/SUPPDOCS/CHINADOC/CHINATTL.HTM
•
Tru64 UNIX Technical Reference for Using Japanese Features:
http://h30097.www3.hp.com/docs/base_doc/
DOCUMENTATION/V51B_HTML/SUPPDOCS/JAPANDOC/TITLE.HTM
•
Tru64 UNIX Technical Reference for Using Korean Features:
http://h30097.www3.hp.com/docs/base_doc/
DOCUMENTATION/V51B_HTML/SUPPDOCS/KOREADOC/KOREATTL.HTM
•
Tru64 UNIX Technical Reference for Using Thai Features:
http://h30097.www3.hp.com/docs/base_doc/
DOCUMENTATION/V51B_HTML/SUPPDOCS/THAIDOC/THAITTL.HTM
•
HP-UX 9.x - 11i Version 2 Internationalization Features White Paper:
http://www.docs.hp.com/en/oshpux11iv2.html
#Internationalization
•
HP-UX 11i Version 2 September 2004 Release Notes, Chapter 11,
Internationalization.
http://docs.hp.com/en/5990–8153/index.html
17–6
Internationalization Support
18
Kernel and Driver Interfaces
Kernel modules (device drivers, file systems, and others) are usually specific to
their operating system, and sometimes they are even version-specific. Therefore,
they are among the most difficult interfaces to port as the interface to the kernel
is rarely compatible between operating systems. This chapter discusses what
functionality is available on HP-UX 11i and how kernel-dependent applications
developed for Tru64 UNIX are affected. It will also provide some suggestions for
API replacements for HP-UX 11i.
18.1 Loadable Kernel Modules
Both Tru64 UNIX and HP-UX 11i support the dynamic loading and unloading of
kernel modules or subsystems. Both platforms also allow these modules to contain
configurable attributes that may be queried and changed while the kernel is
running.
Tru64 UNIX refers to loadable modules as Loadable Kernel Subsystems; HP-UX
11i uses the term Dynamic Loadable Kernel Modules (DLKM). Table 18–1 and
Table 18–2 compare the Tru64 UNIX andHP-UX 11i commands used to load
modules. There are two separate tables because the commands used to manage
loadable kernel modules are in transition and are different in HP-UX 11i v2 and
later.
Table 18–1: Kernel Loadable Module Commands: HP-UX 11i v1.6 and Earlier
Tru64 UNIX
HP-UX 11i v1.6 and
Earlier
Description
sysconfig -c
kmadmin -L
Loads a module to the running
kernel.
sysconfig -u
kmadmin -U (or -u)
Unloads a kernel module.
sysconfig
kmtune
Queries, sets, or resets system
parameters.
autosysconfig
kmsystem
Configures a module to be loaded at
the next system boot.
sourceconfig
config -M
Configures a module for dynamic
loading and generates some files.
sysconfigdb
kmupdate
Updates the kernel with loadable
module.
Not Available
kmmodreg
Registers the DLKM with the
kernel.
Table 18–2: Kernel Loadable Module Commands: HP-UX 11i v2 and Later
Tru64 UNIX
HP-UX 11i v2 and Later
Description
sysconfig -c
kcmodule
modulename=loaded
Loads a module to the running
kernel.
sysconfig -u
kcmodule
modulename=unused
Unloads a kernel module.
sysconfig
kctune
Queries, sets, or resets system
parameters.
Kernel and Driver Interfaces
18–1
Table 18–2: Kernel Loadable Module Commands: HP-UX 11i v2 and Later (cont.)
Tru64 UNIX
HP-UX 11i v2 and Later
Description
autosysconfig
kcmodule
Configures a module to be loaded at
the next system boot.
sourceconfig
kconfig
Configures a module for dynamic
loading and generates some files.
sysconfigdb
kcmodule
Updates the kernel with a loadable
module.
Not Available
kcmodule
Registers the DLKM with the
kernel.
In HP-UX 11i v2 and later, the kcweb Web-based kernel administration utility is
also capable of managing dynamically loadable kernel modules and kernel tunables.
Also, the administration commands are much simpler in that many operations that
previously required a kernel rebuild and system reboot no longer require that.
The steps involved to build loadable kernel modules are very similar between the
two platforms and are well documented.
See the Tru64 UNIX Programmer’s Guide for more information on building
loadable modules for Tru64 UNIX:
http://h30097.www3.hp.com/docs/pub_page/V51B_DOCS/
V51B_DOCLIST.HTM
See the steps in the HP-UX 11i Managing and Developing Dynamically Loadable
Kernel Modules manual for more information on loadable modules for HP-UX 11i:
http://docs.hp.com/hpux/onlinedocs/
dlkm-62001/dlkm-62001.html
Table 18–3 compares the Tru64 UNIX and HP-UX 11i system functions used to
load, unload, query, and configure loadable kernel modules. These functions are
implemented as macros on HP-UX 11i.
Table 18–3: Kernel Loadable Module APIs
18–2
Tru64 UNIX
HP-UX 11i
Description
cfg_configure(9)
modload(2)
Loads a kernel module.
cfg_unconfigure(9)
moduload(2)
Unloads a kernel module.
cfg_query(9)
modstat(2)
Gets the values of selected attributes.
cfg_get_state(9)
modstat(2)
Obtains information about a loaded
module.
Not Available
modpath(2)
Allows users to modify the search
path used to locate object files for
dynamic loading.
Kernel and Driver Interfaces
19
Freeware, Open Source, Public Domain
Software
Many development environments utilize both commercial and freely available
tools. This chapter discusses the availability and development of freely available
(Open Source, Public Domain, and others) applications and libraries.
19.1 HP Provided Software
Like many other operating systems today, HP-UX 11i provides precompiled bundles
of commonly used free software packages. The following sections describe some
of these packages.
19.1.1 Technical Computing Open Source Product
The Technical Computing Open Source Product bundle provides some of the most
commonly requested Open Source tools. This software is provided for free and is not
supported by HP. HP is not responsible for the ported defects from the Open Source
communities. However, HP will report the defects to the related Open Source
community and incorporate the appropriate defect repairs for each new release.
The Technical Computing Open Source Product bundle is installed as part of the
technical computing environment. As such, the Minimum Technical Computing
(MTOE), Technical Computing (TCOE), and Mission Critical (MCOE) operating
environments will install the bundle by default. The bundle includes binaries,
documentation, and libraries. The included libraries are intended for use only by
the included binaries and not for development purposes. The applications included
are shown in Table 19–1.
Table 19–1: Technical Computing Open Source Applications
Bourne Again Shell
/opt/OpenSource/bin/bash
GNU make
/opt/OpenSource/bin/make
CDRecord
/opt/OpenSource/bin/cdrecord,
/opt/OpenSource/bin/mkisofs
GNU Emacs
/opt/OpenSource/bin/emacs
GNU Less
/opt/OpenSource/bin/less
extended C Shell (TENEX-like C Shell)
/opt/OpenSource/bin/tcsh
Vi IMproved
/opt/OpenSource/bin/vim
19.1.2 HP-UX Internet Express
HP-UX Internet Express is a package that provides Open Source components
provided in other HP-UX Operating Environments (OEs) as well as many
components not provided anywhere else. HP-UX Internet Express contains two
sets of components. The first set, shown in Table 19–2, is a collection of over 30
non-OE Open Source Web, Internet, and security components that have been tested
and qualified on HP-UX. The second set of components, shown in Table 19–3, is a
selection of Open Source software products available in various HP-UX OEs and
fully supported by HP unless stated otherwise.
Freeware, Open Source, Public Domain Software
19–1
HP is not responsible for the ported defects from the Open Source communities.
However, HP will report the defects to the related Open Source community and
incorporate the appropriate defect repairs for each new release.
Table 19–2: Non-OE Open Source Components
Calamaris
Curl
Cyrus IMAP
Cyrus SASL
DanteSOCKS
Fetchmail
Horde
Hypermail
IMP
Jabber
Libpcap
Majordomo
MySQL
Net::SSLeay
OpenLDAP
OpenSSL
Perl-LDAP
Pine
PostgreSQL
ProcMail
ProFTPD
Qpopper
SOAP
Squid
Stunnel
TCPdump
UDDI4J
UW-IMAP
Xalan-C
Xerces-C
Table 19–3: OE Open Source Components
/dev/random
Auth_ldap
Bastille
Batik
BIND
bootpd
Bourne Again Shell (bash)
CDRecord/XCDRoast
Cocoon
DNS
elm
FOP
Gated
GNU base
GNU Emacs
GNU LIBC (partial)
GNU make (gmake)
GNU zip (gzip)
HP-UX IPFilter
Jakarta Tomcat
Kerberos Client
Less
mailx
Mod_frontpage
mod_ssl
Mozilla browser
NTP
Perl
PHP
Samba
Secure Apache Web Server
Secure Shell (ssh)
Sendmail
SLP
SNIA
TCP Wrappers
Tcsh
Vi IMproved (VIM)
wu-ftp
Xalan-J
Xerces-J
HP-UX Internet Express is available for download from:
http://software.hp.com/ISS_products_list.html
19.1.3 Ximian GNOME
Ximian GNOME for HP-UX is a modern, highly customizable desktop environment
that runs on top of the X Window System as an alternative to CDE. Ximian
GNOME for HP-UX is a feature-rich desktop environment comprising the sawfish
window manager, the GTK+ graphics libraries, and a set of core applications that
work together to provide a seamless user experience and a portable development
platform.
The current release does not include all of the features of the latest versions of
GNOME available for other platforms. This release is based on GNOME version
1.4. Later versions of GNOME are now available on Linux and some other
19–2
Freeware, Open Source, Public Domain Software
platforms. This product is not supported; therefore, it is not recommended for
mission-critical or production environments.
For more information or to download a kit see:
http://docs.hp.com/en/GNOME/
19.1.4 Mozilla
Beginning with HP-UX 11i v2, the Mozilla Web browser is included on the OS
media and is the recommended browser for HP-UX. Packages are available for
HP-UX 11.0, HP-UX 11i v1, and later. For additional information or to download
the latest kit see:
http://www.hp.com/go/mozilla
The Mozilla package requires that the Ximian GNOME GTK+ libraries be installed
prior to installing Mozilla. These libraries are provided strictly for use by Mozilla
and are not intended for development. Information on obtaining and installing
these libraries is available on the previous Web site.
19.1.5 Cross-Reference for OSSC
Table 19–4 contains a listing of freeware packages that you may have used from
the Tru64 UNIX Open Source Software Collection (OSSC) and where to obtain
these packages for HP-UX 11i. HP does not support any of these products. They
are provided here exclusively for your convenience. The abbreviation HPPD is
used in the table to indicate the package is available from the HP-UX Porting and
Archive Centre. See Section 19.2 and Chapter 20 for more information.
_________________________
Note
_________________________
These URLs have been verified at the time of publication. Due to the
nature of the internet some of them may have become unavailable since.
In that case, try a search engine to find the source code from another
site or visit the DSPP site for an up-to-date listing of available free
software packages:
http://www.hp.com/dspp >> technical resources >> open source
tools list
Table 19–4: Freeware Status and Availability
Package Name
Status/Source URL
ACE
http://www.cs.wustl.edu/~schmidt/ACE.html
Acrobat
Binary only. http://www.adobe.com/products/acrobat/
EmiClock
http://hpux.connect.org.uk/hppd/hpux/X11
/Desktop/emiclock-1.0.2/
FileRunner
V2.5.1 source on OSSC
TiMidity++
http://timidity.sourceforge.net/
bind
http://www.isc.org/products/BIND/
CDRecord
Included in Technical Computing Open Source Product
cpio
http://www.gnu.org/software/cpio/cpio.html
cscope
http://cscope.sourceforge.net/
cygnus_expect
Search for package name “expect” on HPPD site.
cygnus_gcc-g++
Search for package name “gcc” on HPPD site.
Freeware, Open Source, Public Domain Software
19–3
Table 19–4: Freeware Status and Availability (cont.)
Package Name
Status/Source URL
db3
Search for package name “db” on HPPD site.
gmake
Included with the Technical Computing Open Source Product
gtar
Search for package name “tar” on HPPD site.
htmltidy
http://tidy.sourceforge.net/
lftp
http://freshmeat.net/projects/lftp/
libtcl_tk
Search for package name “tcl” on HPPD site.
llnlxdir
ftp://ftp.llnl.gov/pub/ia/llnlxdir/
lsof
Search for package name “lsof” on HPPD site.
mpack
ftp://ftp.andrew.cmu.edu/pub/mpack/
mrolo
http://www.wizzy.com/wizzy/mrolo.html
ralcgm
http://www.agocg.ac.uk/train/cgm/ralcgm.htm
sedt
http://users.rcn.com/anker/sedt/sedt.htm
sh-utils
Search for package name “sh_utils” on HPPD site.
syd
Not Available [specific to Tru64 UNIX]
vmubc
Not Available [specific to Tru64 UNIX]
w3c-libwww
Search for package name “w3c_libwww” on HPPD site.
xmaddressbook
Search for package name “xmaddress” on HPPD site.
xmcdbin
Search for package name “xmcd” on HPPD site.
xperfmonPlus
Not Available [specific to Tru64 UNIX]
zephyr
ftp://athena-dist.mit.edu/pub/ATHENA/zephyr/
19.2 Application Archives
The growth of the Internet has provided developers and system adminstrators
with numerous locations from which to collect precompilied tools and libraries.
These collections allow you to locate required resources without having to search
the entire internet.
HP provides several such archives for both source and binary distributions:
•
OpenSource.hp.com hosts a number of Open Source software projects that run
on various HP platforms including Linux, HP-UX, and Tru64 UNIX at:
http://opensource.hp.com
•
The Developer Solution Partner Portal (DSPP) program maintains a list of
available Open Source and Public Domain software packages that have been
requested by partners at:
http://www.hp.com/dspp >> technical resources >> open source tools list
•
The software depot Web site provides bundles such as Mozilla, Ximian
GNOME, and GTK+ for HP-UX at:
http://software.hp.com
The HP-UX Porting and Archive Centre is a third-party archive, not maintained by
HP, of open source and public domain software for HP-UX. The archive contains
over 2000 precompiled and source packages for both PA-RISC and Itanium®-based
systems. You can access this collection at the primary site:
http://hpux.connect.org.uk/
19–4
Freeware, Open Source, Public Domain Software
There are also multiple mirrors for this site. These additional resources are listed
in Chapter 20. For the best results, HP recommends that you use the mirror
closest to you.
19.3 Building Portable Software
Many portable programs achieve at least part of their portability by using the
autoconf tool. If the source directory contains a file named configure, you will
often find that typing the following is all that is required to get an error-free build:
% ./configure
% make
By default, this will produce a 32-bit executable.
In most cases, when the sources are in C, you can produce a 64-bit executable
by setting the CCOPTS environment variable to the value +DD64 before you run
the configure script.
Sometimes, when working with older packages, the configure script needs help
determining the correct description for the host it is running on. You can supply it
like this:
% ./configure --host=ia64-hp-hpux11.22
You can also obtain the latest version of the GNU config.guess and config.sub
scripts from the following location to replace the ones that came with the package:
ftp://ftp.gnu.org/gnu/config/
Freeware, Open Source, Public Domain Software
19–5
20
Additional Resources
20.1 Software Resources
•
HP software depot home:
http://software.hp.com/
Online store providing instant access to HP software for free trial and purchase.
•
HP-UX Porting and Archive Centre site
Established by the University of Liverpool in England, this is the primary
HP-UX public domain software site.
http://hpux.connect.org.uk — primary site (England)
•
GNU.org:
http://www.gnu.org
•
Perl.com:
http://www.perl.com
•
Perl Mongers:
http://www.perl.org
20.2 Corporate Web Sites
•
HP Web site:
http://www.hp.com/
Companywide information.
•
HP developer and solution partner portal:
http://www.hp.com/dspp
Information resource for software developers.
•
Tru64 UNIX Documentation:
http://www.hp.com/go/tru64docs
Links to Tru64 UNIX documentation.
•
Transitioning Your Tru64 UNIX Applications to HP-UX:
http://www.hp.com/go/tru64appmigration
Links to various resources to assist in moving applications from Tru64 UNIX to
HP-UX
•
HP Online Technical Documentation:
http://docs.hp.com/
General link to HP online documentation documentation.
•
HP-UX 11i v2 Online Documentation:
http://docs.hp.com/hpux/os/11iv2/
Links to HP-UX 11i v2 documentation.
•
HP-UX 11i v1 Online Documentation:
http://docs.hp.com/hpux/os/11iv1/
Additional Resources
20–1
Links to HP-UX 11i v1 documentation.
•
HP-UX 11i Software Transition Kit:
http://www.hp.com/go/STK/
Documents and tools for transitioning software from HP-UX 10.x to HP-UX 11i.
•
HP computer languages and tools home page:
http://www.hp.com/go/lang
HP sites on compilers, debuggers, and performance analysis tools.
•
HP education services:
http://education.hp.com
Site for information on all HP training classes.
•
•
ITRC Maintenance/Support:
–
http://us-support.external.hp.com/common/bin/doc.pl (US)
–
http://europe-support.external.hp.com/
common/bin/doc.pl (Europe)
ITRC Education:
http://education.itresourcecenter.hp.com
ITRC site for HP education from seminars to online training.
•
HP Itanium® home page:
http://www.hp.com/go/itanium
HP’s Future of Computing Web Site.
20.3 User Groups and Other Sites
•
Interex:
http://www.interex.org/
The International Association of Hewlett-Packard Computing Professionals.
•
InterWorks:
http://www.interworks.com/
A forum of professionals within the Interex membership who work in the
HP-UX technical computing environment. They also provide links to local
HP user groups throughout the world.
•
HP/Works:
http://www.hpworks.org.uk/
The HP Technical Computing User Group is an independent group, supporting
all users of HP and Apollo computer systems.
20.4 Newsgroups
•
comp.sys.hp.hardware
Discussion of Hewlett-Packard systems hardware, including workstations,
Xterminals, mainframes, printers, and any other hardware questions except
HP calculators, which are discussed in the comp.sys.hp48 newsgroup.
•
comp.sys.hp.apps
Discussion of software and applications running on any HP platform, although
HP-UX and MPE-specific software solutions are discussed in the corresponding
comp.sys.hp.hpux and comp.sys.hp.mpe newsgroups.
•
20–2
comp.sys.hp.hpux
Additional Resources
Discussion of system administration and other issues pertaining to the HP-UX
operating system.
•
comp.sys.hp.misc
Discussion of issues not covered in any other comp.sys.hp.* newsgroup.
20.5 Mailing Lists
To join, send a message to: [email protected]. Include the following
line in the body of the message:
subscribe list-name
The available list names are:
•
hpux-devtools
Development tools discussion list
•
hpux-devtools-announce
Announcements about other development issues
•
cxx-dev
C++ development discussion list
•
cxx-dev-announce
C++ development announcements
•
caliper
Caliper users
•
caliper-announce
Caliper announcements
Additional Resources
20–3
A
Comparison of Compaq C and HP C and HP
ANSI C Compiler Options
Table A–1 maps the Compaq C compiler options to the corresponding HP C and
HP ANSI C compiler options.
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-accept option1[,option2,..]
Not Available
Causes the compiler
to recognize additional
keywords.
-[no]ansi_alias
+O[no]ptrs_ansi
or
+Otype_safety=ansi
(Itanium® processor family
only)
Directs the compiler to
assume the ANSI C
aliasing rules, which
allows the optimizer to
be more aggressive in its
optimizations.
-[no]ansi_args
Not Available
Tells the compiler that the
source code follows all ANSI
rules about arguments.
-arch level
+DAarchitecture (PA-RISC
only)
Allows the compiler to use
instruction sets up to and
including level.
-assume {
Not Available
[no]array_parameter_restricted_pointers
|
[no]ignore_restricted_pointers |
[no]parameter_restricted_pointers |
[no]restricted_pointers
}
Specifies whether parameters
or pointers are restricted.
-assume [no]math_errno
+O[no]libmerrno (Itanium®
processor family only)
See +O[no]libcalls for
PA-RISC
The compiler assumes that
the program will interrogate
errno after any call to a
math library routine that
is capable of setting errno.
This is the default on Tru64
UNIX; the default for the
Itanium® processor family is
+Onolibmerrno.
-assume whole_program
+Owhole_program_mode
Specifies that no occurrences
of the address-of operator
are being applied outside the
current compilation unit to
extern variables that are
declared inside the current
compilation unit.
-assume [no]aligned_objects
Not Available
Controls the alignment
assumptions for code
generated for indirect load
and store instructions.
-assume
[no]trusted_short_alignment
Not Available
Tells the compiler to
assume that this is a
strictly conforming ANSI
C program with respect
to the dereferencing of
pointer-to-short variables.
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
A–1
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-Bstring
See -t
Specifies a suffix to add to
the normal names of any
components specified with the
-t option.
-C
-C
Prevents the C preprocessor
from stripping comments.
-c
-c
Compiles only; does not link.
Forces an object (.o) file to
be produced for each .c file
even if only one program is
compiled.
-c99
Not Available
Selects strict ANSI C99
language mode.
-call_shared
-dynamic
Produces a shared-link
executable (the default on
both systems).
-check
Not Available
Performs compile-time code
checking.
-[no]check_bounds
Not Available
Generates run-time code to
check the values of array
subscripts.
-check_omp
Not Available
Enables run-time checking of
certain OpenMP constructs.
-check_registry location_file
Not Available
Checks the location of this
shared object’s segments and
makes sure they stay out
of the way of other object’s
segments.
-common
-Ac (PA-RISC only)
Selects K&R language mode.
-compress
Not Available
Causes the output object to
be produced in a compressed
object format.
-cord
Not Available
Runs the procedure
rearranger, cord, on the
resulting file after linking.
-[no]cpp
Not Available
Calls the C macro
preprocessor on C and
assembly source files before
compiling.
-Dname[=def]
-Dname[=def]
Defines the preprocessor
variable name with the value
def. If def is not present, the
value is set to 1.
-double
-fpeval=double (Itanium®
processor family only; this is
the default on PA-RISC with
-Ac)
Promotes expressions of type
float to double. This is the
default for Compaq C when
-std0 is used.
-E
-E
Runs only the C macro
preprocessor on the files
and sends the result to the
standard output device.
-e epsym
See linker (Appendix D)
See linker (Appendix D).
A–2
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-edit[0-9]
Not Available
When syntactic or semantic
errors are detected by the
compiler’s frontend, it invokes
the editor defined by the
EDITOR environment variable
(or vi if EDITOR is undefined).
-error_limit nn
Use the aCC_MAXERR=nn
environment variable on the
Itanium® processor family, or
the MAXERRORS environment
variable on PA-RISC
Sets a limit on the number of
error-level diagnostics that
the compiler will emit.
-exact_version
See linker (Appendix D)
See linker (Appendix D).
-expect_unresolved pattern
See linker (Appendix D)
See linker (Appendix D).
-FIfilename
Not Available
Specifies a file that is to be
included before the first line
in a source file is actually
compiled.
-fast
-fast
Selects a combination of
compilation options typically
used for optimum execution
time.
-feedback file
+Oprofile=use:filename
or
+df filename (PA-RISC
only)
Specifies that the compiler
should use the profile
information contained in
the file when performing
optimizations.
-fini symbol
See linker (Appendix D)
See linker (Appendix D)
-float
+f (with -Ac on PA-RISC only) Prevents the compiler from
promoting expressions of type
-fpeval=float (Itanium®
processor family only)
float to type double. This
is the default for Compaq
C (except in-std0 mode)
and for HP ANSI C on
Itanium®-based platforms.
-float_const
Not Available
Causes the compiler to assign
floating-point constants of
type float (rather than
double) if their values can
be represented in single
precision.
-[no]fp_reorder
+O[no]fltacc
Allows floating-point
operations to be reordered
during optimization.
-fprm option
Not Available
Specifies rounding mode.
-fptm n
+FPiuOVZ
Generates instructions that
do not trigger floating-point
underflow or inexact trapping
modes.
-fptm u
+FPOUVZ
Generates traps on
floating-point underflow
as well as overflow,
divide-by-zero, and invalid
operation.
-framepointer
Not Available
Makes all procedures in the
source file use $fp (register
15) as the frame pointer.
-g0
Not Available
Produces only enough symbol
table information for linking.
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
A–3
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-g, -g2, -g3
-g0
Produces symbol table
information for full symbolic
debugging.
-g1
-g1
Produces limited symbol table
information for debugging.
-gen_feedback
+Oprofile=collect
Generates accurate profile
information to be used with
the -feedback optimizations.
-granularity size
Not Available
Controls the size of shared
data in memory that can be
safely accessed from different
threads.
-Hc
Not Available
Halts compiling after the pass
specified by the character c,
producing an intermediate
file for the next pass.
-hpath
See -t
Specifies the directory where
the tool (or other component)
specified with -t is located.
-I
Not Available
Does not search
/usr/include for header
files.
-Idir
-Idir
Adds the dir directory to the
list of directories searched for
include files.
-ieee
Default
Ensures support of all
portable features in the
IEEE Standard for Binary
Floating-Point Arithmetic,
including treatment of
denormalized numbers,
NaNs, and infinities and the
handling of error cases.
-ifo
Not Available
Performs interfile
optimizations.
-[no]inline keyword
+inline_level [i] num
(Itanium® processor family only)
or
+O[no]inline
Specifies whether to provide
inline expansion of functions.
-init symbol
See linker (Appendix D)
See linker (Appendix D).
-input_to_ld filename
-Wl,-c,filename
Directs the linker to read the
contents of filename as if the
contents had been supplied on
the ld command line.
-[no]intrinsics
Not Available
Enables the compiler to
recognize certain functions as
intrinsic functions.
-isoc94
Not Available
Causes the macro
__STD_VERSION__ to be
passed to the preprocessor.
-K
+Oreusedir=path (PA-RISC
only)
Directs the compiler to
give recognizable names to
intermediate files and retain
them for debugging purposes.
-Ldir
See linker (Appendix D)
See linker (Appendix D).
-l
See linker (Appendix D)
See linker (Appendix D).
A–4
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-M
+Make (Itanium® processor
family only)
Outputs a set of make
dependency rules to standard
output.
-MD
+Maked (Itanium® processor
family only)
Requests dependency files
from the preprocessor.
-machine_code
Not Available, see -S
Includes the generated
machine code in the listing
file.
-[no]member_alignment
Not Available
Directs the compiler to
byte-align data structure
members (the default is to
align data structure members
on natural boundaries).
-[no]misalign
+u1
Assumes that there are no
aligned objects.
-mp
Not Available
Causes the compiler to
recognize an older form
of parallel programming
directives, as well as OpenMP
directives, and pass libots3
and appropriate thread
libraries to the linker.
-ms
Not Available
Selects Microsoft language
mode, which provides some
compatibility with the
Microsoft Visual C compiler.
-msg_always
Not Available
Always emit the messages
identified by the msg_list
argument.
-msg_disable
+Warg1[,arg2,...]
Disables a specific message or
group of messages.
-msg_dump
Not Available
Causes the compiler to dump
to stdout all messages
enabled by any given cc
command.
-msg_enable
Not Available
Enables a specific message or
group of messages.
-msg_error
+Wearg1[,arg2,...]
Changes the identified
messages to be errors.
-msg_fatal
Not Available
Changes the identified
messages to be fatal.
-msg_inform
Not Available
Changes the identified
messages to be informational.
-msg_once
Not Available
Emits the identified messages
to be fatal, compilation-ending
errors.
-msg_warn
+Wwarg1[,arg2,...]
Changes the identified
messages to be warnings.
-nestlevel=n
Not Available
Sets the nesting-level limit
for include files.
-noarchive
See linker (Appendix D)
See linker (Appendix D).
-nocurrent_include
-I-
Changes the behavior of
the #include “filename”
directive to not search the
source file’s directory for
filename.
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
A–5
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-non_shared
See linker (Appendix D)
See linker (Appendix D).
-noobject
-o /dev/null
Suppresses the creation of an
object file.
-nopg
Not Available
Does not place information in
the object file used by gprof
for profiling.
-Olevel
-Olevel
Sets the optimization level to
level.
-o output
-o output
Names the final output file
output.
-oldcomment
Not Available
Directs the preprocessor to
delete comments.
-om
Not Available
Performs code optimization
after linking, including nop
removal.
-omp
+Oopenmp
Recognizes the OpenMP APIs.
-P
-P
Only performs preprocessing.
-p[n]
-p
Determines the level of
profiling.
-pg
-G
Places information in the
object file used by gprof for
profiling.
-[no]pids
Not Available
Enables (or disables) the
addition of the process ID to
the filename of the basic block
counts file (.Counts).
-portable
Not Available
Directs the compiler to
issue diagnostics for certain
constructs that may not be
portable to other compilers or
platforms.
-preempt_module
-Bdefault (Itanium®
processor family only)
Supports symbol preemption
on a module-by-module basis.
-preempt_symbol
-Bextern
Supports symbol preemption
on a symbol-by-symbol basis.
-prof_dir
Use the FLOW_DATA
environment variable with
+Oprofile=collect
or
+df filename
(PA-RISC only)
Specifies a location to which
the profiling data files are
written.
-prof_gen
+Oprofile=collect
Generates an executable
image that has profiling code
added to it.
-prof_gen_noopt
+Oprofile=collect +O0
Generates a nonoptimized
executable image that has
profiling code added to it.
-prof_use_feedback
+Oprofile=use[:filename]
Uses profiling feedback
to improve compiler
optimization.
-prof_use_om_feedback
Not Available
Uses profiling feedback to
rearrange the resulting image
to reduce cache conflicts of the
program text.
A–6
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-protect_headers keyword
Not Available
Ensures that the compiler’s
assumptions about pointer
sizes and data alignments are
not in conflict with the default
values that were in effect
when the system libraries
were created.
-proto[is]
Not Available
Extracts prototype
declarations for function
definitions and puts them in a
.H suffixed file.
-pthread
-mt (Itanium® processor family Directs the linker to use
thread-safe versions of any
only, see Chapter 8)
library specified with the
-l option when linking
programs.
-Q
Not Available
Directs the preprocessor to
use single quotes in __FILE__
expansions instead of double
quotes.
-readonly_strings
+Olit=all (Itanium®
processor family)
+ESlit (PA-RISC)
Allows the compiler to assume
that string literals are
read-only.
-rpath path
See linker (Appendix D)
See linker (Appendix D).
-S
-S
Compiles the specified source
files and generates symbolic
assembly language output.
-SD[directory]
Not Available
Suppresses certain warning
and informational-level
diagnostic messages that
are inappropriate for system
header files.
-scope_safe
Not Available
Ensures that any trap (such
as floating-point overflow)
is reported to have occurred
in the procedure or guarded
scope that caused the trap.
-set_version version_string
Not Available
Establishes the version
identifier associated with a
shared library.
-shared
See linker (Appendix D)
See linker (Appendix D).
-show keyword (except -show symbols, see
below)
Not Available
Specifies one or more items to
be included in the listing file.
-show symbols
+m (PA_RISC only)
Produces a macro and symbol
table map in the source
listing.
-signed
Default
Causes all unqualified char
declarations to have the
same representation and
range of values as signed
char declarations. This is the
default.
-soname soname
See linker (Appendix D)
See linker (Appendix D).
-source_listing
+L[p] (PA-RISC only)
Produces a source program
listing file.
-speculate all
Not Available
Specifies that speculation
may occur anywhere in the
executable image.
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
A–7
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-speculate by_routine
Not Available
Specifies that speculation is
allowed only in the code in the
source module that is being
compiled.
-spike
Not Available
Invokes the spike tool to
perform code optimization
after linking a program.
-std
-Ae
Enables ANSI C compliance
with “value-added features”
and “Extended ANSI”.
-std0
-Ac (PA-RISC only)
Selects K&R language mode.
-std1
-Aa
Selects strict ANSI language
mode.
-strong_volatile
Not Available
Affects the generation of code
for assignments to objects
that are less than or equal to
16 bits in size (for instance
char, short) that have been
declared as volatile.
-taso
See Section 2.5.4
Directs the linker to load the
executable file in the lower
31-bit addressable virtual
address range.
-tc[c...]
-tx,name
Tru64 UNIX: Specifies
which compiler passes the
-h and -B options apply to.
HP-UX 11i: Substitutes
name in place of subprocess x
of the compiler.
-threads
Not Available
(see Chapter 8)
Directs the linker to use
the thread-safe version of
any library specified with
the -l option when linking
programs.
-traditional
-Ac (PA-RISC only)
Selects the K&R language
mode.
-trapuv
Not Available
Forces all uninitialized stack
variables to be initialized with
0xfff58005fff58005.
-tune model
+DSmodel
Instructs the optimizer to
tune the application for
a specific version of the
hardware.
-Uname
-Uname
Removes any macro definition
of name at the start of
compilation.
-unroll [n]
+O[no]loop_unroll[=n]
Controls the loop unrolling
optimization.
-unsigned
+uc
Causes all char declarations
to have the same
representation and range
of values as unsigned char
declarations.
A–8
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
Table A–1: Comparison of Compaq C and HP C and HP ANSI C Compiler Options (cont.)
Compaq C
HP C (PA-RISC) and
HP ANSI C (Itanium®
Processor Family)
Description
-update_registry location_file
Not Available
Registers the location of this
shared object’s segments and
makes sure they stay out
of the way of others in the
location_file.
-V
-V
Prints the version of the
compiler to standard error.
-v
-v
Prints the compilation phases
as they execute.
-varargs
Not Available
Prints warnings for all
lines that may require the
<vaargs.h> macros.
-vaxc
Not Available
Selects VAX C language mode.
-verbose
Not Available
Produces longer error and
warning messages.
-volatile
+Ovolatile
Tru64 UNIX: Causes
all variables to be
treated as volatile.
HP-UX 11i: Causes all
global variables to be treated
as volatile.
-Wc[c...],arg1[,arg2,...]
-Wc,arg1
Passes the argument, or
arguments, to the compiler
pass, or passes (c[c...]).
-w[n]
-w[n] or +w[n] or -W c
Sets the warning messages
level.
-warnprotos
+Ww2223(aCC6 on
Itanium® processor family)
+Ww972,444 (aCC5 on
Itanium® processor family)
+Ww714 (PA-RISC)
Causes the compiler to
produce warning messages
when a function is called that
is not declared with a full
prototype.
-weak_volatile
Not Available
Affects the generation of code
for assignments to objects
that are less than or equal to
16 bits in size that have been
declared as volatile.
-writable_strings
+Olit=none (Itanium®
processor family)
+ESnolit (PA-RISC)
Causes all string literals to be
writable (Compaq C default).
-xtaso
See Section 2.5.4
Causes the compiler to respect
#pragma pointer_size
directives, which control the
size of pointers.
-xtaso_short
+DD32 (see Section 2.5.4)
Same as the -xtaso option,
except -xtaso_short also
directs the compiler to allocate
32-bit pointers by default.
-Zp[n]
Not Available
Aligns structure members
based on the integer n, where
n can be 1, 2, 4, or 8.
Comparison of Compaq C and HP C and HP ANSI C Compiler Options
A–9
B
Comparison of Compaq C++ and HP aC++
Compiler Options
Table B–1 maps the Compaq C++ compiler options to the corresponding HP aC++
compiler options.
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options
Compaq C++
HP aC++
Description
-accept [no]restrict_keyword
-Drestrict=__restrict
Recognizes restrict as a
keyword.
-alternative_tokens
Not Available
Enables the use of operator
keywords and digraphs to
generate tokens.
-[no]ansi_alias
+Otype_safety=ansi
Assumes ANSI C aliasing rules
to allow generating better
optimized code.
-arch option
+DAarchitecture (PA-RISC only)
Generates instructions for a
specified architecture.
-assume
[no]accuracy_sensitive
+O[no]fltacc
Allows the compiler to reorder
floating-point operations for
improved performance.
-assume
[no]aligned_objects
Not Available
Assumes that a pointer object
points to an aligned object to
generate better code for pointer
dereferences.
Not Available
-assume {[no]
array_parameter_restricted_pointers
|
[no]ignore_restricted_pointers |
[no]parameter_restricted_pointers |
[no]restricted_pointers
}
Specifies whether parameters or
pointers are restricted.
-assume gfullpath
Not Available
Inserts the full pathname into
the object file when compiling
with -g.
-assume [no]math_errno
+O[no]libmerrno (Itanium®
processor family only)
See +O[no]libcalls for
PA-RISC
Controls the assumption about
a program’s dependence on
the setting of errno by math
library routines. -assume
math_errno is the default on
Tru64 UNIX; the default for the
Itanium® processor family is
+Onolibmerrno.
-assume [no]ptrs_to_globals
Not Available
Assumes that global variables
have had their addresses taken
in separately compiled modules.
-assume [no]trusted_short_alignment
Not Available
Assumes any short accessed
through a pointer is naturally
aligned.
-assume [no]whole_program
+O[no]whole_program_mode
Asserts that the whole program
consists of a single object
module.
-Bstring
See -t
Specifies a suffix to add to the
normal names of components
specified with the -t option.
Comparison of Compaq C++ and HP aC++ Compiler Options
B–1
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-C
-C
Prohibits the preprocessor from
removing comments in the
source file.
-c
-c
Suppresses the linking phase of
the compilation.
-call_shared
-dynamic
Produces a dynamic executable
(the default for both compilers).
-comp.config directory
Not Available
Specifies a directory for the
comp.config file.
-[no]compress
Not Available
Causes the output object file
to be produced in compressed
object file format.
-cord
Not Available
Runs the procedure rearranger
on the resulting file after
linking.
-cpp
Not Available
Runs the preprocessor on the
source files before compiling.
-create_pch filename
Not Available
Creates a precompiled header
file with the specified name.
-Dname [=def]
-Dname[=def]
Defines name to the preprocessor
as if #define name def were
prepended to the C++ source file.
-D__FORCE_INSTANTIATIONS
Not Available
Forces the standard library
preinstantiations to be created
in the users repository.
-D__[NO_]USE_STD_IOSTREAM
See Table 4–4
Uses standard iostreams.
-define_templates
Not Available
Automatically instantiates
templates completely and places
them in output object.
-denorm
+FPD
Forces denormalized constant
numbers to zero when IEEE
support is enabled.
-distinguish_nested_enums
Default
Changes the compiler’s name
mangling scheme to include the
name of any class within which
an enum type is nested.
-E
-E
Runs only the preprocessor on
the source files and sends the
results to standard output.
-error_limit n,
-noerror_limit
Use aCC_MAXERR=nn
environment variable
Specifies the number of errors
allowed before compilation stops
for a single source file.
-fast
-fast
Sets compiler options and
symbols to improve run-time
performance.
-feedback file
+Oprofile=use:filename
or
+dffilename (PA-RISC only)
Tru64 UNIX: This option is
used with the -cord option
to specify a feedback file.
HP-UX 11i: Specifies the
pathname of the profile database
to use with profile-based
optimization.
-[no]fp_reorder
+O[no]fltacc
-fprm option
Not Available
B–2
Comparison of Compaq C++ and HP aC++ Compiler Options
Same as -assume
[no]accuracy_sensitive
Specifies rounding mode.
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-fptm n
+FPiuOVZ
Generates instructions that
do not trigger floating-point
underflow or inexact trapping
modes.
-fptm u
+FPOUVZ
Generates traps on
floating-point underflow as
well as overflow, divide-by-zero,
and invalid operations.
-g, -g2
-g0
Generates full information for
debugging.
-gall
Not Available
Generates full symbol table
information for all classes,
structs, and unions.
-gall_pattern pattern
Not Available
Generates full symbol table
information for all classes,
structs, and unions if the name
of the file matches pattern.
-G num
Not Available
Specifies the maximum size of
the data item to be accessed
from the global pointer.
-gen_feedback
+Oprofile
Generates profile information
to be used with -feedback
optimizations.
-[no]global_array_new
Not Available
Controls whether calls to the
global array new and delete are
generated as specified by ANSI.
-hdir
See -t
Uses the specified directory
instead of the directory where
name specified by the -t flag is
normally found.
-Hc
Not Available
Halts compiling after the pass
specified by character c.
-I
-I-
Does not search for #include
files in the standard directories.
-Idir
-Idir
Defines the directory name
dir to the preprocessor for use
in searching for quoted and
angle-bracketed include files.
-ieee
Default
Supports all portable features of
the IEEE standard.
-[no]implicit_include
+inst_implicit_include
(deprecated)
Enables inclusion of source files
as a method of finding template
definitions. This is the default
on Tru64 UNIX, but not on
HP-UX 11i.
-[no]inline keyword
+inline_level [i]num
(Also +O[no]inline and
+Oinlinebudget=n)
Specifies whether to provide
inline expansion of functions.
-[no]intrinsics
Not Available
Recognizes intrinsic functions
automatically, based only on
name and call signature.
-K
Not Available
Builds and uses intermediate
files.
-long_double_size 64 | 128
Not Available
Specifies 64-bit or 128-bit long
doubles (128-bit is the default on
Tru64 UNIX Version 5.x).
Comparison of Compaq C++ and HP aC++ Compiler Options
B–3
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-M
+Make
Produces Makefile
dependencies instead of the
usual output and sends it to
standard output.
-MD
+Maked
Like -M, but produces a
dependency file which has the
suffix .d appended to the object
file name.
-MDffilename
use +Maked -o filename for
similar functionality
Same as -MD, except that
dependencies are written to the
specified file.
-machine_code
Not Available; see -S
Lists generated machine code in
a listing file.
-[no]member_alignment
Not Available
Default is to align data structure
members on natural boundaries.
-nomember_alignment directs
compiler to byte-align data
structure members.
-[no]misalign
+u1
Specifies that code not generate
alignment faults.
-model [ansi | arm]
Not Available
-model arm is the default
and allows linking against
pre-v6.3 objects. -model ansi
supports complete ISO/ANSI
specification, including distinct
name mangling for templates.
-msg_disable tag
+Warg1[,arg2,...,argN]
Disables message. Can be used
for any non-error message.
-msg_display_number
Default
Displays the error number at
the beginning of each message.
-msg_display_tag
Not Available
Displays a more descriptive tag
at the end of each message.
-msg_enable tag
Not Available
Enables specific messages that
would normally not be enabled.
-msg_error tag
+Wearg1[,arg2,...,argN]
Also similar to +p
Increases message(s) severity to
error.
-msg_inform tag
Not Available
Reduces message(s) severity to
informational.
-msg_quiet
similar to -w
Issues fewer messages.
-msg_warn tag
Not Available
Reduces message(s) severity to
warning.
-no_current_include
-I-
Does not search for quoted
include files in the directory
containing the source file with
the #include line.
-nocleanup
Not Available
Disables generation of implicit
exception handlers.
-nocxxstd
+nostl (see reference page for Instructs the driver not to
caution about using this option) include libcxxstd.a when
linking.
-nodemangle
-Wf,-o
Causes linker messages to
contain mangled names.
-noexceptions
+noeh
Disables C++ exception
handling.
-nolibcxx
Not Available
Instructs the driver not to
include libcxx when linking.
B–4
Comparison of Compaq C++ and HP aC++ Compiler Options
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-non_shared
See linker (Appendix D)
Does not produce a dynamic
executable.
-noobject
-o /dev/null
Does not produce an object file.
-nopragma_template
Not Available
Ignores any #pragma
define_template directives.
-nopreinst
Not Available
Forces the standard library
instantiations in the users
repository to be preferred at
link time over the ones in the
standard library. Use with
-D__FORCE_INSTANTIATIONS.
-nopt
+inst_directed
Disables automatic template
instantiation and places
manually instantiated templates
in an output object.
-novtable_info
Not Available
Tells the demangler to suppress
display of internal symbols.
-o file
-o file
Names the output file.
-O[n]
+O[n] or -O[n]
Specifies the level of
optimization.
-om
Not Available
Performs code optimization after
linking.
-omp
+Oopenmp
Recognizes OpenMP APIs.
-P
-P
Runs only the preprocessor and
puts the result for each source
file in a corresponding .ixx file
on Tru64 UNIX, and a .i file on
HP-UX 11i.
-p
-p
Performs profiling using prof.
-pch
Not Available
Automatically uses and/or
creates a precompiled header
file.
-pch_dir
Not Available
Specifies the directory in which
to search for and/or create a
precompiled header file.
-[no]pch_messages
Not Available
Enables or disables the display
of a message indicating that
a precompiled header file was
created or used in the current
compilation.
-pending_instantiations n
Not Available
Limits the depth of recursive
instantiations.
-pg
-G
Prepares the object file for use
with gprof.
-preempt_module
-Bdefault (Itanium® processor Provides module preemption but
not full symbol preemption.
family only)
-preempt_symbol
-Bextern
Provides full symbol preemption.
-protect_headers [all|none|full]
Not Available
Enables protection of system
header files.
-pt
Not Available
Automatically instantiates
templates into the repository
with external linkage.
-pthread
-mt
Uses thread-safe version of
libraries, uses POSIX threads
interfaces, defines _REENTRANT
macro.
Comparison of Compaq C++ and HP aC++ Compiler Options
B–5
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-ptr dir
Not Available
Specifies a repository.
-ptsuf
+inst_include_suffixes
Specifies file name suffixes for
template definition files.
-ptv
Not Available
Turns on verbose mode to display
each phase of instantiation as it
occurs.
-[no]pure_cname
Not Available
Used with <cname> headers
to define C namespaces in
namespace std only.
-r
See linker (Appendix D)
Retains relocation entries in
output file.
-readonly_strings
+Olit=all (Itanium®
processor family)
+ESlit (PA-RISC)
Makes all string literals
readable only. This is the default
on both platforms.
-[no]rtti
Not Available
Enables or disables support for
run-time type identification.
-S
-S
Compiles source and generates
symbolic assembly language
output.
-SD[directory]
Not Available
Suppresses certain warning and
informational-level messages
that are inappropriate for
system header files.
-shared
See linker (Appendix D)
Produces a shared object.
-show keyword,[keyword,...]
Not Available
Specifies one or more items to be
included in the listing file.
-show_mangled_name
-Wf,-o
Tells the demangler to display an
encoded name after a demangled
name.
-signed
Default
Causes all char declarations to
have the same representation as
signed char declarations. This is
the default.
-source_listing
Not Available
Produces a source-code listing.
-[no]stdnew
Not Available
Controls whether calls are
generated to the ANSI or
pre-ANSI implementation of the
operator new().
-std ansi
Not Available
ANSI C++ with commonly used
extensions.
-std arm
-Aarm (aCC6 onItanium®
processor family)
Used to compile programs
developed using Compaq C++
Version 5.n.
-std cfront
Not Available
Compiles code developed using a
cfront-based compiler.
-std gnu
-Aarm (aCC6 onItanium®
processor family)
Compiles code developed using
the GNU compiler.
-std ms
Not Available
Compiles code using some
Microsoft Visual C++ compatible
extensions.
-std strict_ansi
-AA
Compiles code strictly enforcing
the ANSI standard with strict
error checking.
-std strict_ansi_errors
Not Available
Issues errors for all ANSI
violations.
B–6
Comparison of Compaq C++ and HP aC++ Compiler Options
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-strong_volatile
Not Available
Generates load-locked
instructions for assignments to
objects that are <= 16 bits in size
that have been declared volatile.
-tc[c...]
-tx,name
Tru64 UNIX: Specifies
which compiler passes the
-h and -B options apply to.
HP-UX 11i: Substitutes name
in place of subprocess x of the
compiler.
-tall
Not Available
Automatically instantiates
templates completely and places
them in an object file.
-tall_repository
Not Available
Automatically instantiates
templates completely and places
them in a repository.
-taso
See Section 2.5.4
Tells the linker that the
executable file should be loaded
in the lower 31–bit addressable
virtual address range.
-timplicit_local
Not Available
Same as -tlocal, except
manually instantiated templates
are placed in the repository with
external linkage.
-tlocal
Not Available
Instantiates templates
automatically and places
them in the output object with
internal linkage. Templates are
instantiated in every module
that uses them.
-trapuv
Not Available
Forces all unitialized stack
variables to be initialized to
0xfff58005fff58005.
-ttimestamp
Not Available
Instantiates templates only if
existing ones are older than the
timestamp in the repository,
or if they do not exist in the
repository.
-tune option
+DSmodel
Selects processor-specific
instruction tuning.
-tused
+inst_compiletime
Places automatically
instantiated templates in
the output object (this is the
default on HP-UX 11i).
-tused_repository
Not Available
Places manually instantiated
templates in the repository.
-tweak
Not Available
Same as -timplicit_local,
but automatically instantiated
templates receive weak linkage,
so duplicate symbols do not
cause errors.
-Uname
-Uname
Cancels any command-line
definition of name to the
preprocessor.
-underflow_to_zero
+FPD
When used with the -ieee
option, directs the compiler to
flush floating-point underflows
to zero.
-unroll [n]
+O[no]loop_unroll [=n]
Controls loop unrolling.
Comparison of Compaq C++ and HP aC++ Compiler Options
B–7
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-unsigned
+uc
Causes all char declarations to
have the same representation as
unsigned char declarations.
-use_ld_input=filespec
-nouse_ld_input
Not Available
-use_ld_input=filespec causes
a linker options file containing
names of template instantiation
files to be saved in the repository.
-nouse_ld_input causes the
names of template instantiation
files to be recorded on the
command line.
-use_non_shared_libcxx
Not Available
Instructs the driver to use the
nonshared version of libcxx.
-use_pch filename
Not Available
Uses a precompiled header file
of the specified name as part of
the current compilation.
-[no]use_system_libcxx
Not Available
Uses or does not use the libcxx
that is bundled with the compiler
or instead uses the one bundled
with the operating system.
-[no]using_std
Not Available
Compiles as if using
namespace std; were at
the top of the source file(s).
-v
-v
Prints the names of compiler
phases as they execute.
-V
-V
Prints the compiler version.
-verbose
Not Available
Includes identifiers with
diagnostic messages for use with
#pragma message directives or
as arguments to -msg_disable
options.
-volatile
+Ovolatile (PA-RISC only)
Tru64 UNIX: Causes
all variables to be
treated as volatile.
HP-UX 11i: Causes all
global variables to be treated as
volatile.
-vptr_size, -vptr_size_short
See Section 2.5.4
Sets the default size of the
virtual function and virtual
base pointers to 64 bits
(-vptr_size), or 32 bits
(-vptr_size_short). Enables
#pragma pointer_size and
passes -taso to linker.
-w, -w2
-w
Suppresses warning messages.
-w0
+w
Displays all levels of compiler
messages.
-Wc[c...],arg1[,arg2...]
-Wc,arg1[,arg2...]
Passes argument(s) to compiler
pass(es) c[c...].
-weak_volatile
Not Available
Does not generate load-locked
instructions for assignments to
objects that are <= 16 bits in size
that have been declared volatile.
-writable_strings
+Olit=none (Itanium® processor family)
+ESnolit (PA-RISC)
Makes string literals writable.
-x language
Not Available
Treats file names as language
source files regardless of
suffixes.
B–8
Comparison of Compaq C++ and HP aC++ Compiler Options
Table B–1: Comparison of Compaq C++ and HP aC++ Compiler Options (cont.)
Compaq C++
HP aC++
Description
-xref, -xref_stdout
Not Available
Generates a data file that
Compaq FUSE uses to create
a cross-reference database file.
-xref_stdout sends the output
to standard output.
-xtaso
See Section 2.5.4
Enables #pragma
pointer_size and passes
-taso to the linker.
-xtaso_short
+DD32 (see Section 2.5.4)
Sets the default pointer size to
32 bits.
-Zp[n]
Not Available
Aligns structure members as
specified by n, which can be 1,
2, 4, or 8 bytes.
Comparison of Compaq C++ and HP aC++ Compiler Options
B–9
C
Comparison of Compaq Fortran and HP
Fortran Compiler Options
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options
Compaq Fortran
HP Fortran
Description
-1
+cfc -1
Executes at least one iteration of DO loops.
-66
+cfc -66
Allows extensions that enhance
FORTRAN-66 compatibility.
-align arg
+cfc -align arg
Tells the compiler to add padding bytes in
COMMON blocks or structures.
-[no]altparam
+cfc -[no]altparam
Allows the alternate nonstandard syntax
for PARAMETER statements.
-annotations
Not Available
Requests that annotations be added to the
source listing, indicating which of a set of
optimizations were applied to particular
parts of the source.
-arch
+DAmodel (PA-RISC only)
Determines which version of the
architecture the compiler generates
instructions for.
[no]accuracy_sensitive or
+O[no]fltacc
+cfc -assume
Reorders floating-point operations,
based on algebraic identities (inverses,
associativity, and distribution), to improve
performance.
-assume [no]backslash
+cfc -assume [no]backslash
FORTRAN 77 only. Treats the backslash
(\) character literally in character literals.
-assume bigarrays
Not Available
Suppresses run-time checking for
distributed small array dimensions.
+cfc -assume
Tells the compiler to set the default
for opening sequential output files to
BUFFERED=’YES’.
-assume [no]byterecl
+cfc -assume [no]byterecl
Specifies (for unformatted data files) that
the units for the OPEN statement RECL
specifier (record length) value are in bytes,
not four-byte units.
-assume cc_omp
Not Available
Enables conditional compilation as defined
by the OpenMP Fortran API.
+cfc -assume
Assumes that dummy (formal) arguments
to procedures share memory locations
with other dummy arguments or with
COMMON variables that are assigned.
-assume gfullpath
Not Available
Causes the full source file path to be
included in the debug information.
-assume [no]minus0
+cfc -assume [no]minus0
Tells the compiler to use F95 standard
semantics for the treatment of IEEE
floating value -0.0 in the SIGN intrinsic, if
the processor is capable of distinguishing
the difference between -0.0 and +0.0.
-assume
[no]accuracy_sensitive
-assume [no]buffered_io
-assume [no]dummy_aliases
[no]buffered_io
[no]dummy_aliases or
+O[no]parmsoverlap
-assume noprotect_constants Not Available
Specifies that a copy of a constant actual
argument is to be passed, so it can be
modified by the called routine, even
though the Fortran standard prohibits
such modification.
Comparison of Compaq Fortran and HP Fortran Compiler Options
C–1
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-assume nosource_include
Not Available
Tells the compiler to search the default
directory for INCLUDE files (same as
when -vms is used).
+cfc -assume
Appends underscores or not.
-assume nozsize
Not Available
Omits run-time checking for zero-sized
array sections for increased performance
with the -hpf option.
-assume pthreads_lock
Not Available
Tells the compiler to use restrictive locking
for unnamed critical sections.
-[no]automatic
+cfc -[no]automatic or
+nosave
Places local variables on the run-time
stack.
-C
-C
Generates code to perform run-time checks
on array subscript and character substring
expressions (same as the -check bounds
option).
-c
-c
Suppresses the loading phase of the
compilation and forces an object file to
be produced even if only one program is
compiled.
-call_shared
-dynamic
Tells ld(1) to produce a dynamic
executable.
-ccdefault
Not Available
Specifies the type of carriage control used
when a file is displayed at a terminal.
-check arg_temp_created
Not Available
Generates code to check if actual
arguments are copied into temporary
storage before routine calls.
-check bounds
+cfc -check bounds
Generates code to perform run-time checks
on array subscript and character substring
expressions.
-check [no]format
+cfc -check [no]format
Issues the run-time FORVARMIS fatal
error when the data type of an item being
formatted for output does not match the
format descriptor being used
-check nopower
Not Available
Suppresses the run-time errors for
0.0**0.0 and <negative-value>**<integervalue-of-type-real>, so 0.0**0.0 is 1.0 and
(-3.0)**3.0 is -27.0.
-check omp_bindings
Not Available
Provides run-time checking to enforce the
OpenMP binding rules.
-assume [no]underscore
[no]underscore or
+[no]ppu
-check [no]output_conversion +cfc -check
[no]output_conversion
Issues the run-time OUTCONERR
continuable error message when a data
item is too large to fit in a designated
format descriptor field.
-check overflow
Not Available
Generates code to trap on integer overflow.
-check underflow
Not Available
Produces a message at run time to warn
that floating-point underflow has occurred.
-col72
+cfc -col72 or
+noextend_source
Treats the statement field of each source
line as ending in column 72.
-convert format
+cfc -convert format
Determines which format is used to read
and write unformatted files.
-cord
Not Available
Runs the cord(1) procedure-rearranger
on the resulting file after linking. This
rearrangement reduces the cache conflicts
of the program’s text.
C–2
Comparison of Compaq Fortran and HP Fortran Compiler Options
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-[no]cpp
+cfc -[no]cpp or
+cpp[=none]
Runs cpp(1) on all Fortran source files
before compiling.
-cross_reference
Not Available
Includes in the listing (if one is generated
with -V), a cross-reference of all symbols
used in the source program, along with
line numbers of definitions and uses (same
as the -show xref option).
-D num
See Appendix D
See Appendix D.
-Dname[=def]
-Dname[=def]
Defines the name as def for use by
either cpp(1) or fpp(1) for conditional
compilation.
-distribute num
Not Available
Specifies the number of processors that do
not share memory on which the program
will execute.
-double_size 64
+autodbl
Defines DOUBLE PRECISION
declarations, constants, functions,
and intrinsics as REAL*8.
-double_size 128
Not Available
Defines DOUBLE PRECISION
declarations, constants, functions,
and intrinsics as REAL*16.
-d_lines
+cfc -d_lines or
+d_lines
Compiles lines having a D in column 1 of
the source program. The default is to treat
such lines as comments.
-EB
Not Available
Produces big-endian byte order.
-error_limit num
Not Available
Specifies the maximum number of
error-level or fatal-level compiler errors
allowed for a file specified on the command
line.
-extend_source
+cfc -extend_source or
+extend_source
Treats the statement field of each source
line as ending in column 132, instead of
column 72.
-[no]f66
+cfc -[no]f66
Tells the compiler to apply FORTRAN-66
semantics.
-f77
Not Available
Enforces FORTRAN 77 semantics.
-f77rtl
Not Available
Tells the compiler to use the run-time
behavior of Compaq Fortran 77 instead of
Compaq Fortran.
-fast
Not Available
Sets some command options that can
improve run-time performance.
-feedback file
Tru64 UNIX: Specifies the file
+Oprofile=use:filename
(Itanium® processor family only) to be used by cord(1) or the
compiler for further optimizations.
HP-UX 11i: Specifies the pathname of the
profile database to use with profile-based
optimization.
-fixed
+cfc -fixed or
+source=fixed
Interprets Fortran source files as fixed
(FORTRAN 77 style) source format.
-fpconstant
+cfc -fpconstant or
+real_constant=double
or -R8
Extends the precision of single-precision
constants, assigned to double-precision
variables, to double precision.
-fpe0 or -fpe
+cfc -fpe0 or +cfc -fpe or
+fp_exception -Wl,-FPD
Terminates a program if a floating-point
operation results in overflow, division by
zero, or if the operands are exceptional
values.
Comparison of Compaq Fortran and HP Fortran Compiler Options
C–3
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-fpe1
+cfc -fpe1 or
+fp_exception
Continues program execution and
generates an Infinity or NaN if a
floating-point operation results in
overflow, division by zero, or invalid data.
-fpe2
Not Available
Continues program execution if a
floating-point operation results in
overflow, division by zero, or invalid data.
-fpe3
Not Available
Continues program execution if a
floating-point operation results in
overflow, division by zero, invalid data, or
underflow.
-fpe4
Not Available
Continues program execution if a
floating-point operation results in
overflow, division by zero, invalid data, or
underflow.
-fpp
Not Available
Runs fpp(1) on all Fortran files before
compiling.
-fprm option
Not Available
Specifies rounding mode.
-fptm x
Not Available
Tells cc(1) how to support exception
handling.
-[no_]fp_reorder
+cfc -[no_]fp_reorder or
+[no]Ofltacc
Reorders floating-point operations,
based on algebraic identities to improve
performance. This option is the inverse of
the -assume [no]accuracy_sensitive
option.
-free
+cfc -free or
+source=free
Interprets Fortran source files as free
source format.
-fuse_xref
Not Available
Directs the compiler to generate a data
file that the Compaq FUSE Database
Manager uses to create a cross-reference
database file.
-g[n]
-g
Produces symbol table information for
debugging.
-gen_feedback
+Oprofile=collect
(Itanium® processor family
only)
Directs the compiler to generate code that
will produce accurate feedback information
when profiled.
-granularity {byte |
longword | quadword }
Not Available
Ensures that data of the size specified can
be accessed from different threads sharing
data in memory.
-hpf [num]
+parallel
Compiles the program to run in parallel
(pre-MPI).
-hpf_target
Not Available
Specifies the message-passing protocol
to use between processors for programs
running in parallel.
-I
Not Available
Prevents cpp(1) from searching for
include files in the standard directory
/usr/include.
-Idir
-Idir
Directs the search for cpp(1) #include
files.
-i{2|4|8}
+cfc +i{2|4|8}
Sets size of default integer and logical
variables.
-ident
Not Available
Specifies that what(1) style identification
strings be placed in the object file.
-inline all
+cfc -inline all or
+Oinline
Inlines every procedure call that can be
inlined while still generating correct code.
-inline manual
Not Available
Inlines only statement functions.
C–4
Comparison of Compaq Fortran and HP Fortran Compiler Options
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-inline none
+cfc -inline none or
+Onoinline
Suppresses all inlining of routines.
-inline size
Not Available
Inlines calls where inlining will not
significantly increase program size, plus
any additional calls that the compiler
determines will improve run-time
performance.
-inline speed
+cfc -inline speed or
+Oinline
Inlines calls that will likely improve
run-time performance.
-intconstant
Not Available
Uses FORTRAN 77 rather than Fortran
90 semantics to determine kind for integer
constants.
-integer_size {16|32|64}
+cfc -integer_size
{16|32|64}
Sets size of default integer and logical
variables. 4 bytes is the default.
-K
+cpp keep
Keeps the temporary files produced by
cpp(1) or the compiler.
-ko output
Not Available
Tells cc(1) the name for the output file
created by the ucode loader.
-L
See Appendix D
See Appendix D.
-Ldir
See Appendix D
See Appendix D.
-lstring
Not Available
Searches the libstring libraries for ld
(see ld(1)).
-ladebug
Not Available
Includes additional symbolic information
in the object file for the ladebug(1)
debugger.
-M
Not Available
Tells cpp(1) to generate dependency
lists suitable for make(1) instead of the
normal output.
-[no]machine_code
+cfc -[no]machine_code or
+[no]extend_source
Includes in the listing (if one is generated)
a machine language representation of the
compiled code.
-math_library {accurate|fast}
+cfc -math_library
{accurate|fast} or
+nofastintrinsics
Specifies that the compiler is to select
the version of the math library routine
which provides the most accurate result
or the best performance for mathematical
intrinsic functions. fast is a no-op on
HP-UX 11i.
-math_library fast
Not Available
Specifies that the compiler is to select
the version of the math library routine
that provides the highest execution
performance for certain mathematical
intrinsic functions, such as EXP and
SQRT.
-[no]member_alignment
+cfc -[no]member_alignment
Same as -align [no]records
-mixed_str_len_arg
Not Available
Tells the compiler that the hidden length
passed for a character argument is to be
placed immediately after its corresponding
character argument in the argument list.
-module directory
+cfc -module directory or
+moddir= directory
Outputs .mod files to a directory.
-mp
+parallel
Enables parallel processing using directed
decomposition. Parallel processing is
directed by inserting !$PAR directives in
your source code.
-names as_is
Not Available
Causes the compiler to distinguish case
differences in identifiers and to preserve
the case of external names.
Comparison of Compaq Fortran and HP Fortran Compiler Options
C–5
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-names {uppercase|lowercase}
+cfc -names
{uppercase|lowercase} or
+[no]uppercase
Causes the compiler to ignore case
differences in identifiers and to convert
external names to uppercase or lowercase.
-nearest_neighbor num
Not Available
Enables the nearest neighbor parallel
optimization. The optional num parameter
specifies the maximum width of the
shadow edge to use.
-noD
Recognized and ignored with
+cfc
Tells the driver not to pass any -Dname or
-Uname options to the compiler.
-noerror_limit
Not Available
Specifies that there is no limit to the
number of error-level or fatal-level
compiler errors allowed for a file specified
on the command line.
-nof77
+cfc -nof77
Allows extensions that enhance
FORTRAN-66 compatibility.
-nofor_main
Not Available
Specifies that the main program is not
written in Fortran, and prevents the
compiler from linking for_main.o into
applications.
-nofpp
+cpp=no
Does not run fpp(1) (or cpp(1)) on
Fortran source files before compiling.
-nohpf_main
Not Available
Specifies that the HPF global routine
being compiled will be linked with a main
program that was not compiled with -hpf.
-noi4
-i2 or -integer_size 16
Makes the default integer and logical
variables 2 bytes long.
-noinclude
Not Available
Prevents the compiler from searching in
/usr/include for files specified in a
Compaq Fortran INCLUDE statement.
-non_shared
-N
Prevents ld(1) from producing a dynamic
executable.
-nonearest_neighbor
Not Available
Disables the nearest neighbor parallel
optimization.
-nopipeline
Not Available
Disables the use of instruction scheduling
for certain innermost loops.
-norun
+cfc -norun or +_
Directs the driver not to execute the
compiler and other phases of the process.
-notransform_loops
Not Available
Disables a group of loop transformation
optimizations that apply to array
references within loops.
-nov
Recognized and ignored
Do not print compiler passes as they
execute.
-nowsf_main
Not Available
This option is the same as -nohpf_main.
-Olevel
-Olevel
Sets the optimization level to level.
-Olimit num
Not Available
Tells cc(1) to NOOPT if a routine is too
big.
-o output
-o output
Names the final output file output. The
a.out file is unaffected.
-old_f77
Not Available
Tells the Compaq Fortran 77 driver to
execute the Compaq Fortran 77 compiler
instead of the Compaq Fortran 90 compiler.
-om
Not Available
Performs code optimization after linking,
including NOP (No Operation) removal,
.lita removal, and reallocation of
common symbols.
C–6
Comparison of Compaq Fortran and HP Fortran Compiler Options
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-[no]omp
+cfc -[no]omp or
+O[no]openmp
Enables OpenMP directives.
-onetrip
+cfc -onetrip or +onetrip
Executes at least one iteration of DO loops.
-P
Not Available
Runs only cpp(1) and puts the result for
each source file in a corresponding .i (or
Fortran 90 .i90) file, after processing by
any appropriate preprocessors.
-p0
+noprof or +nogprof
Does not permit profiling.
-p1 or -p
+prof
Sets up profiling by periodically sampling
the value of the program counter for use
with the prof(1) postprocessor. This
option only affects loading.
-[no]pad_source
+cfc -[no]pad_source or
+[no]padsrc
Specifies that fixed-form source records
shorter than the statement field width are
to be padded with spaces on the right, out
to the end of the statement field.
-pg
+gprof
Sets up profiling for gprof(1), which
produces a call graph showing the
execution of the program.
-[no]pipeline
+cfc -[no]pipeline or
+O[no]pipeline
Applies instruction scheduling to certain
innermost loops, allowing instructions
within a loop to "wrap around" and execute
in a different iteration of the loop.
-pthread
Recognized and ignored with
+cfc
Informs the linker to use threaded libraries
(see the -reentrancy keyword options).
HP Fortran does this automatically.
-qlx
See Appendix D
See Appendix D.
-r8
+cfc -r8 or +r8
Defines REAL declarations, constants,
functions, and intrinsics as DOUBLE
PRECISION (REAL*8), and defines
COMPLEX declarations, constants,
functions, and intrinsics as DOUBLE
COMPLEX (COMPLEX*16).
-r16
Not Available
Defines REAL and DOUBLE PRECISION
declarations, constants, functions, and
intrinsics as REAL*16.
-real_size 32
+real_constant=single
Defines REAL declarations, constants,
functions, and intrinsics as REAL*4,
and defines COMPLEX declarations,
constants, functions, and intrinsics as
COMPLEX (COMPLEX*8).
-real_size 64
+real_constant=double
Defines REAL declarations, constants,
functions, and intrinsics as DOUBLE
PRECISION (REAL*8), and defines
COMPLEX declarations, constants,
functions, and intrinsics as DOUBLE
COMPLEX (COMPLEX*16).
-real_size 128
Not Available
Defines REAL and DOUBLE PRECISION
declarations, constants, functions, and
intrinsics as REAL*16.
-[no]recursive
+cfc -[no]recursive or
-automatic
Compiles all FUNCTION and
SUBROUTINE procedures for possible
recursive execution.
-reentrancy {asynch
|threaded | none}
Recognized and ignored with
+cfc
Tells the Compaq Fortran RTL whether
the program will be relying on threaded
or asynchronous (AST) reentrancy. HP
Fortran automatically selects thread-safe
versions of run-time libraries when
appropriate.
Comparison of Compaq Fortran and HP Fortran Compiler Options
C–7
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-S
-S
Creates a listing file of the compiled source
that can be assembled.
-shared
-dynamic
Produces a dynamic shareable object for
inclusion in a shared library.
-show [no]code
+cfc -show [no]code or
+asm
Includes in the listing (if one is generated)
a machine language representation of the
compiled code.
-show hpf[option]
Not Available
Sends information related to
parallelization to standard error
and to the listing (if one is generated).
-show hpfinfo
Not Available
This option is the same as -show
hpf_all.
-show include
Not Available
Includes in the listing (if one is generated)
any text file specified with INCLUDE in
the source program.
-show nomap
Not Available
Excludes from the listing (if one is
generated) information about the symbols
used in the source program.
-show wsfinfo
Not Available
This option is the same as -show hpfinfo
and -show hpf_all.
-show xref
Not Available
Includes in the listing (if one is generated)
a cross-reference of all symbols used
in the source program, along with line
numbers of definitions and uses (same as
the -cross_reference option).
-source_listing
+list
Creates a source listing file with various
compile-time information appended like
-V.
-speculate {all |
by_routine | none}
+cfc -speculate
{all | none} or
+O[no]static_prediction
Performs speculative execution
optimization.
-stand mia
Not Available
Adds MIA extensions to FORTRAN 77.
-stand semantic
Not Available
Causes the compiler to issue informational
messages for statements that conform
to the ANSI Standard but become
nonstandard because of how they are used.
-stand source_form
Not Available
Causes the compiler to issue informational
messages for statements that use tab
formatting or contain lowercase characters
outside of character literals and comments.
-stand syntax
Not Available
Causes the compiler to issue informational
messages for syntax extensions to the
ANSI Standard.
-static
+cfc -static or -K or
-noautomatic
Causes all local variables to be statically
allocated.
-std
Not Available
Produces warnings for things that are not
standard in the language.
-std90
Not Available
Produces warnings for things that are not
standard in the Fortran 90 language.
-std95
Not Available
Produces warnings for things that are not
standard in the Fortran 95 language.
-synchronous_exceptions
Not Available
Causes the compiler to generate TRAPB
instructions after every floating-point
instruction.
-syntax_only
Not Available
Specifies that the source file will be
checked only for correct syntax.
C–8
Comparison of Compaq Fortran and HP Fortran Compiler Options
Table C–1: Comparison of Compaq Fortran and HP Fortran Compiler Options (cont.)
Compaq Fortran
HP Fortran
Description
-systype name
Not Available
Names the compilation environment.
-T num
See Appendix D
See Appendix D.
-taso
See Appendix D
See Appendix D.
-threads
Recognized and ignored with
+cfc
Informs the linker to use threaded
libraries. HP Fortran does this
automatically.
-[no]transform_loops
+cfc -[no]transform_loops
or +O[no]loop_transform
Specifies a group of loop transformation
optimizations that apply to array
references within loops.
-tune
+DSmodel
Selects processor-specific instruction
tuning.
-Uname
-Uname
Tells cpp(1) to remove any initial
definition of name.
-u
+cfc -u or
+implicit_none
Sets the default type of a variable as
undefined (IMPLICIT NONE), which
causes the compiler to issue a warning for
any undeclared symbols.
-unroll num
Not Available
Sets the depth of loop unrolling done by
the optimizer.
-V
Not Available
Creates a source listing file with various
compile-time information appended.
-v
-v
Prints the passes as they execute with
their arguments and their input and
output files.
-version
+version
Prints the version strings of the Fortran
command and compiler.
-vms
Not Available
Causes the run-time system to behave
like Compaq Fortran on OpenVMS Alpha
systems.
-Wl,arg1[,arg2...]
-Wc
-Wp,arg1[,arg2...]
-Wp
Passes options arg1[ arg2]... to cpp(1)
that the driver does not normally pass to
the preprocessor.
-w
-w
Disables all warning messages.
-w1
Not Available
Disables warnings about unused variables.
-warn arg
Not Available
Enables/disables warnings of the type
specified by arg.
-warning_severity error
Not Available
Turns all messages that are normally
warnings into errors.
-warning_severity stderror
Not Available
Issues an error message instead of a
warning for standard violations.
-what
+cfc -what or +what
Prints the version strings of the Fortran
command and the compiler.
-wsf [num]
Not Available
This option is the same as -hpf.
-wsf_target
Not Available
This option is the same as -hpf_target.
Passes options arg1[arg2]... to
ld(1).
cc(1) for
Comparison of Compaq Fortran and HP Fortran Compiler Options
C–9
D
Comparison of the Tru64 UNIX and HP-UX
11i Linker Options
Table D–1 compares the Tru64 UNIX and HP-UX 11i linker switches and provides
mapping where possible. A complete match may not be possible, so the match
shows the best possible. See the linker manual or man pages for details on all
of the options.
Table D–1: Comparision of the Tru64 UNIX and HP-UX 11i Linker Options
Tru64 UNIX
HP-UX 11i
Description
-A file
Not Available
Performs incremental linking.
-all
+forceload or -Fl archive Includes all symbols from all objects/archives,
for PA32
including those symbols that are not
referenced.
-B num
Not Available
Sets the bss segment origin.
-B bind
-B bind
Differences in bind options supported, see
Section 5.2.5.
-b
Not Available
Does not merge the symbolic information
entries for the same file into one entry for that
file.
-call_shared
-dynamic
Produces a dynamic executable. This is the
default on both platforms.
-check_registry location_file
Not Available
Checks the location of this shared object’s
segments and makes sure they stay out of the
way of other object’s segments in location_file.
-D num
-D num
Sets the data segment origin. See Section 5.2.2
for details.
-d
Not Available
Forces definition of common storage and
linker-defined symbols even if -r is present.
-dc
-d
Forces definition of common storage.
-depth_ring_search
-B symbolic
Uses depth-first symbol resolution. See
Section 5.2.4.
-e epsym
-e epsym
Sets the default entry point address for the
output file to be that of the epsym.
-error_unresolved
+noallowunsats
Produces a fatal error message when
unresolved symbols are encountered.
-exact_version
Not Available
Requires that the same library be used at link
time and run time.
-exclude object
Not Available
Excludes the specified object from the shared
object being created by the linker.
-exported_symbol pattern
+ee symbol
Turns off the -hidden option for a single
symbol. HP-UX 11i matches exact symbols;
Tru64 UNIX matches patterns.
-expect_unresolved pattern
Not Available
Ignores any unresolved symbols that match
pattern. HP-UX 11i turns the error/warning
off for all symbols.
-F or -z
Not Available
Creates a ZMAGIC (demand paged) output file.
-f fill
Not Available
Establishes a fill pattern for use in filling the
last page of the text section of a ZMAGIC file
to the page boundary.
Comparison of the Tru64 UNIX and HP-UX 11i Linker Options
D–1
Table D–1: Comparision of the Tru64 UNIX and HP-UX 11i Linker Options (cont.)
Tru64 UNIX
HP-UX 11i
Description
-fini symbol
+fini symbol
Makes the procedure symbol into a termination
routine.
-fixed
Not Available
The library will either be mapped at its
quickstart address or the load will fail with
a message.
-g or -g[123]
+noobjdebug
Includes debugging information in image.
Prior to HP-UX 11i v1.6 this was the default.
The default is now to not place debug
information in the final image but to leave it
in the object files.
-hidden
+hideallsymbols
Converts all external symbols from objects
following this option into local symbols. On
Tru64 UNIX this option is position-sensitive;
HP-UX 11i applies the last option specified
globally.
-hidden_symbol symbol
-h symbol
Converts symbol into a local symbol
(position-sensitive).
-init symbol
+init symbol
Makes the procedure symbol into an
initialization routine.
-input filename
-c filename
Directs the linker to read the contents of file
filename as if the contents had been supplied
on the command line.
-Kdir
LPATH=dir;
see Section 5.1.3
Eliminates the search of the default library
directories and instead causes ld to search the
single directory dir.
-L
LPATH=/dev/null;
see Section 5.1.3
Changes the library directory search order so
that the defaults are never searched.
-Ldir
-L dir
Searches dir for dependent libraries before
looking in the default library directories.
-lx
-lx
Includes library libx.{so|a} in link.
-M
+vtype files
Produces a UNIX BSD4.3–like load map.
-m
-m
Produces a UNIX System V-like load map.
-msym
+gst
Produces a hash of the dynamic symbols for
faster run-time resolution.
-N
-N
Creates an OMAGIC (impure) output file. On
HP-UX 11i, available in 32-bit mode only.
-n
Not Available
Creates an NMAGIC (shared text) output file.
-nN
Not Available
Creates an NMAGIC (shared text) output file.
-noarchive
-a shared
Resolves to shared objects (position-sensitive).
-nolibrary_replacement
+noenvvar
Loader ignores the run-time environment
when locating dependent libraries.
-non_hidden
-E
Turns off the -hidden option. To turn off the
-hidden option for a single symbol, use the
-exported_symbol option. On Tru64 UNIX
this option is position-sensitive; HP-UX 11i
applies the last option specified globally.
-non_shared
-noshared
Produces a static executable.
-none
+noforceload
Turns off the -none/+noforceload option.
-noprefix_recognition
Not Available
Disables the automatic recognition of symbols
prefixed with __init_ as initialization
routines, as well as disabling the automatic
recognition of symbols prefixed with __fini_
as termination routines.
D–2
Comparison of the Tru64 UNIX and HP-UX 11i Linker Options
Table D–1: Comparision of the Tru64 UNIX and HP-UX 11i Linker Options (cont.)
Tru64 UNIX
HP-UX 11i
Description
-noso
-a archive
Resolves to archive libraries (positionsensitive).
-O0
Not Available
Turns off all code optimizations performed by
the linker. This is the default setting for both
platforms.
-O[12]
Not Available
Enables link-time optimizations.
-O3
-O
Enables link-time optimizations, available
with the PA-RISC 32-bit linker only.
-o outfile
-o outfile
Produces an output object file with the name
outfile.
-old_init_order
Not Available
Requests that the execution order of init
routines match the link order of the objects
and archive libraries from which the routines
are loaded.
-oldstyle_liblookup
-shared_archive
Causes ld to search each library directory,
first for the shared object library and then
for the archive library. This is the default on
HP-UX 11i.
-om
Not Available
Generates an OMAGIC file suitable for input to
the om postlink optimizer.
-qlx
Not Available
Links the library x if found, and silently
ignores it if it is not available.
-r
-r
Retains relocation entries in the output file.
-reverse_init_order
Not Available
Reverses the execution order of init routines.
-rpath path
+b path
Stores path in the image for locating dependent
libraries at execution.
-S
Not Available
Suppresses nonfatal errors.
-s
-s
Strips the symbolic information from the
output object file.
-set_version versionstring
See Section 13.3.1
Establishes the version identifier associated
with a shared library.
-shared
-b
Produces a shared object. Note: On HP-UX
11i, the internal name of a shared library is
not automatically set. See +h.
-so_archive
-a shared_archive
Resolves to either shared objects or archive
libraries (position-sensitive).
-soname soname
+h soname
Sets the internal library name to soname.
-T num
-R num
Sets the text segment origin. See Section 5.2.2
for details.
-taso
See Section 2.5.4
Instructs the loader to map the image into
32-bit addressable memory.
-transitive_link
Not Available
Recursively adds dependencies to the image.
-u symname
-u symname
Enters symname as an undefined symbol.
-update_registry location_file Not Available
Registers the location of this shared object’s
segments and make sure they stay out of the
way of others in the location_file.
-V
-V
Prints the version of ld being used.
-VSnum
Not Available
Uses num as the decimal version stamp.
-v
-v
Sets verbose mode.
-warning_unresolved
+allowunsats
Produces a warning message when unresolved
symbols are encountered.
Comparison of the Tru64 UNIX and HP-UX 11i Linker Options
D–3
Table D–1: Comparision of the Tru64 UNIX and HP-UX 11i Linker Options (cont.)
Tru64 UNIX
HP-UX 11i
Description
-x
-x
Removes local (non-.globl) symbols from the
output symbol table; preserves external and
static symbols only.
-ysym
-y sym
Indicates each file in which sym appears,
sym’s type, and whether the file defines or
references sym.
D–4
Comparison of the Tru64 UNIX and HP-UX 11i Linker Options
E
Supported Locales
Note that locales using the UTF-8 or Latin-9 (ISO8859–15) codesets support the
euro characters, while locales with a @euro suffix define the local currency sign to
be the euro character. On Tru64 UNIX, the suffixes are .UTF8, .ISO8859–15, and
@euro. On HP-UX 11i, the suffixes are .utf8, .iso8859–15, and @euro.
On HP-UX 11i v2, some system support for Latin and South American utf8 locale
binaries are not delivered due to disk space considerations. However, source
files for the locales are provided under /usr/lib/nls/loc/src, and you may
build these binaries by using the localedef command. See the localedef(1M)
reference pages for more information.
Table E–1: Supported Locales
Language
Tru64 UNIX
HP-UX 11i
Arabic (Algeria)
Not Available
ar_DZ.arabic8
Arabic (Saudi Arabia)
Not Available
ar_SA.iso88596
ar_SA.arabic8
Bulgarian
Not Available
bg_BG.iso88595
C
C
C
C.iso88591
C.iso885915
C.iso885915@euro (HP-UX 11i
v1.6 and higher)
C.utf8
Catalan
ca_ES
Not Available
ca_ES.ISO8859-1
ca_ES.ISO8859-15
ca_ES.UTF-8
Chinese (People’s Republic of China)
zh_CN
zh_CN.utf8
zh_CN@ucs4
zh_CN.hp15CN
zh_CN.GBK
zh_CN.GB18030 (Tru64 UNIX
zh_CN.gb18030
V5.1A and later)
zh_CN.UTF-8
zh_CN.dechanzi
zh_CN.dechanzi@ucs4
zh_CN.dechanzi@pinyin
zh_CN.dechanzi@radical
zh_CN.dechanzi@stroke
zh_CN.dechanzi@pinyin@ucs4
zh_CN.dechanzi@radical@ucs4
zh_CN.dechanzi@stroke@ucs4
Supported Locales
E–1
Table E–1: Supported Locales (cont.)
Language
Tru64 UNIX
HP-UX 11i
Chinese (Hong Kong)
zh_HK.big5
zh_HK.hkbig5
zh_HK.dechanyu
zh_HK.big5 (HP-UX 11i v1 only)
zh_HK.dechanyu@ucs4
zh_HK.dechanzi
zh_HK.utf8
zh_HK.dechanzi@ucs4
zh_HK.eucTW
zh_HK.eucTW@ucs4
zh_HK.UTF-8
Chinese (Taiwan)
zh_TW
zh_TW@ucs4
zh_TW.big5
zh_TW.ccdc
zh_TW.big5
zh_TW.eucTW
zh_TW.big5@chuyin
zh_TW.big5@radical
zh_TW.utf8
zh_TW.big5@stroke
zh_TW.dechanyu
zh_TW.dechanyu@chuyin
zh_TW.dechanyu@radical
zh_TW.dechanyu@stroke
zh_TW.dechanyu@chuyin@ucs4
zh_TW.dechanyu@radical@ucs4
zh_TW.dechanyu@stroke@ucs4
zh_TW.dechanyu@ucs4
zh_TW.eucTW
zh_TW.eucTW@chuyin
zh_TW.eucTW@radical
zh_TW.eucTW@stroke
zh_TW.eucTW@chuyin@ucs4
zh_TW.eucTW@radical@ucs4
zh_TW.eucTW@stroke@ucs4
zh_TW.eucTW@ucs4
zh_TW.UTF-8
Croatian
Not Available
hr_HR.iso88592
Czech
cs_CZ
cs_CZ.iso88592
cs_CZ.ISO8859-2
cs_CZ.ISO8859-2@ucs4
cs_CZ@ucs4
cs_CZ.UTF-8 (Tru64 UNIX
V5.1B only)
Danish
da_DK.ISO8859-1
da_DK.iso88591
da_DK.ISO8859-15
da_DK.iso885915@euro
da_DK.UTF-8
da_DK.roman8
nl_NL.ISO8859-1
nl_NL.ISO8859-15
nl_NL.iso88591
nl_NL.iso885915@euro
nl_NL.UTF-8
nl_NL.roman8
English with Euro
en_EU.UTF-8@euro
Not Available
English (Great Britian)
en_GB.ISO8859-1
en_GB.iso88591
en_GB.ISO8859-15
en_GB.iso885915@euro
en_GB.UTF-8
en_GB.roman8
Dutch
E–2
Supported Locales
Table E–1: Supported Locales (cont.)
Language
Tru64 UNIX
HP-UX 11i
English (United States)
en_US.ISO8859-1
en_US.iso88591
en_US.ISO8859-15
en_US.roman8
en_US.UTF-8
en_US.UTF-8@euro
en_US.cp850
Finnish
Flemish
fi_FI.ISO8859-1
fi_FI.iso88591
fi_FI.ISO8859-15
fi_FI.UTF-8
fi_FI.iso885915@euro
fi_FI.roman8
nl_BE.ISO8859-1
Not Available
nl_BE.ISO8859-15
nl_BE.UTF-8
French (Belgium)
fr_BE.ISO8859-1
fr_BE.ISO8859-15
Not Available
fr_BE.UTF-8
French (Canada)
fr_CA.ISO8859-1
fr_CA.iso88591
fr_CA.ISO8859-15
fr_CA.UTF-8
fr_CA.iso885915
fr_CA.iso885915@euro (HP-UX
11i v1.6 and higher)
fr_CA.roman8
fr_CA.utf8
French (France)
French (Switzerland)
fr_FR.ISO8859-1
fr_FR.ISO8859-15
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.UTF-8
fr_FR.roman8
fr_FR.utf8
fr_CH.ISO8859-1
fr_CH.ISO8859-15
Not Available
fr_CH.UTF-8
German (Germany)
de_DE.ISO8859-1
de_DE.iso88591
de_DE.ISO8859-15
de_DE.UTF-8
de_DE.iso885915@euro
de_DE.roman8
de_DE.utf8
German (Switzerland)
de_CH.ISO8859-1
Not Available
de_CH.ISO8859-15
de_CH.UTF-8
Greek
Hebrew
el_GR.ISO8859-7
el_GR.iso88597
el_GR.ISO8859-7@ucs4
el_GR.greek8
el_GR.UTF-8 (Tru64 UNIX
V5.1B only)
el_GR.utf8
iw_IL
iw_IL.ISO8859-8
iw_IL.hebrew8
iw_IL.iso88598
iw_IL.ISO8859-8@ucs4
iw_IL@ucs4
Hebrew (deprecated)
he_IL
he_IL.ISO8859-8
Not Available
he_IL.ISO8859-8@ucs4
he_IL@ucs4
Supported Locales
E–3
Table E–1: Supported Locales (cont.)
Language
Tru64 UNIX
Hungarian
hu_HU
HP-UX 11i
hu_HU.iso88592
hu_HU.ISO8859-2
hu_HU.ISO8859-2@ucs4
hu_HU.UTF-8 (Tru64 UNIX
V5.1B only)
hu_HU@ucs4
Icelandic
is_IS.ISO8859-1
is_IS.ISO8859-15
is_IS.iso88591
is_IS.iso885915@euro
is_IS.roman8
Italian
it_IT.ISO8859-1
it_IT.iso88591
it_IT.ISO8859-15
it_IT.UTF-8
it_IT.iso885915@euro
it_IT.roman8
it_IT.utf8
Japanese
ja_JP
ja_JP.SJIS
ja_JP.SJIS
ja_JP.SJIS@ucs4
ja_JP.eucJP
ja_JP.kana8
ja_JP.UTF-8
ja_JP.utf8
ja_JP.eucJP
ja_JP.deckanji
ja_JP.deckanji@ucs4
ja_JP.sdeckanji
Korean
ko_KR
ko_KR.KSC5601
ko_KR.eucKR
ko_KO.utf8
ko_KR.UTF-8
ko_KR.deckorean
ko_KR.deckorean@ucs4
ko_KR.eucKR
ko_KR@ucs4
Lithuanian
lt_LT.ISO8859-4
lt_LT.UTF-8 (Tru64 UNIX
Not Available
V5.1B only)
lt_LT
Norwegian
no_NO.ISO8859-1
no_NO.ISO8859-15
no_NO.iso88591
no_NO.iso885915@euro
no_NO.UTF-8
no_NO.roman8
POSIX
POSIX
POSIX
Polish
pl_PL
pl_PL.iso88592
pl_PL.ISO8859-2
pl_PL.ISO8859-2@ucs4
pl_PL.UTF-8 (Tru64 UNIX
V5.1B only)
pl_PL@ucs4
Portuguese (Brazil)
Not Available
pt_BR.iso88591 (HP-UX 11i v2
and higher)
pt_BR.iso885915 (HP-UX 11i v2
and higher)
pt_BR.utf8 (HP-UX 11i v2 and
higher)
E–4
Supported Locales
Table E–1: Supported Locales (cont.)
Language
Tru64 UNIX
HP-UX 11i
Portuguese (Portugal)
pt_PT.ISO8859-1
pt_PT.iso88591
pt_PT.ISO8859-15
pt_PT.iso885915@euro
pt_PT.UTF-8
pt_PT.roman8
Rumanian
Not Available
ro_RO.iso88592
Russian
ru_RU
ru_RU.ISO8859-5
ru_RU.iso88595
ru_RU.ISO8859-5@ucs4
ru_RU.UTF-8
ru_RU@ucs4
Slovak
sk_SK
sk_SK.ISO8859-2
sk_SK.iso88592
sk_SK.ISO8859-2@ucs4
sk_SK.UTF-8 (Tru64 UNIX
V5.1B only)
sk_SK@ucs4
Slovene
sl_SI
sl_SI.ISO8859-2
sl_SI.iso88592
sl_SI.UTF-8 (Tru64 UNIX
V5.1B only)
Spanish (Argentina)
Not Available
es_AR.iso88591 (HP-UX 11i v2
and higher)
es_AR.iso885915 (HP-UX 11i v2
and higher)
es_AR.utf8 (HP-UX 11i v2 and
higher)
Spanish (Bolivia)
Not Available
es_BO.iso88591 (HP-UX 11i v2
and higher)
es_BO.iso885915 (HP-UX 11i v2
and higher)
Spanish (Chile)
Not Available
es_CL.iso88591 (HP-UX 11i v2
and higher)
es_CL.iso885915 (HP-UX 11i v2
and higher)
es_CL.uft8 (HP-UX 11i v2 and
higher)
Spanish (Columbia)
Not Available
es_CO.iso88591 (HP-UX 11i v2
and higher)
es_CO.iso885915 (HP-UX 11i v2
and higher)
es_CO.utf8 (HP-UX 11i v2 and
higher)
Spanish (Costa Rica)
Not Available
es_CR.iso88591 (HP-UX 11i v2
and higher)
es_CR.iso885915 (HP-UX 11i v2
and higher)
Spanish (Ecuador)
Not Available
es_EC.iso88591 (HP-UX 11i v2
and higher)
es_EC.iso885915 (HP-UX 11i v2
and higher)
Supported Locales
E–5
Table E–1: Supported Locales (cont.)
Language
Tru64 UNIX
Spanish (El Salvador)
Not Available
HP-UX 11i
es_SV.iso88591 (HP-UX 11i v2
and higher)
es_SV.iso885915 (HP-UX 11i v2
and higher)
Spanish (Guatemala)
Not Available
es_GT.iso88591 (HP-UX 11i v2
and higher)
es_GT.iso885915 (HP-UX 11i v2
and higher)
Spanish (Mexico)
Not Available
es_MX.iso88591 (HP-UX 11i v2
and higher)
es_MX.iso885915 (HP-UX 11i
v2 and higher)
es_MX.utf8 (HP-UX 11i v2 and
higher)
Spanish (Nicaragua)
Not Available
es_NI.iso88591 (HP-UX 11i v2
and higher)
es_NI.iso885915 (HP-UX 11i v2
and higher)
Spanish (Panama)
Not Available
es_PA.iso88591 (HP-UX 11i v2
and higher)
es_PA.iso885915 (HP-UX 11i v2
and higher)
Spanish (Paraguay)
Not Available
es_PY.iso88591 (HP-UX 11i v2
and higher)
es_PY.iso885915 (HP-UX 11i v2
and higher)
Spanish (Peru)
Not Available
es_PE.iso88591 (HP-UX 11i v2
and higher)
es_PE.iso885915 (HP-UX 11i v2
and higher)
es_PE.utf8 (HP-UX 11i v2 and
higher)
Spanish (Puerto Rico)
Not Available
es_PR.iso88591 (HP-UX 11i v2
and higher)
es_PR.iso885915 (HP-UX 11i v2
and higher)
es_PR.utf8 (HP-UX 11i v2 and
higher)
Spanish (Spain)
Spanish (Uraguay)
es_ES.ISO8859-1
es_ES.iso88591
es_ES.ISO8859-15
es_ES.iso885915@euro
es_ES.UTF-8
es_ES.roman8
es_ES.utf8
Not Available
es_UY.iso88591 (HP-UX 11i v2
and higher)
es_UY.iso885915 (HP-UX 11i v2
and higher)
es_UY.utf8 (HP-UX 11i v2 and
higher)
E–6
Supported Locales
Table E–1: Supported Locales (cont.)
Language
Tru64 UNIX
Spanish (Venezuela)
Not Available
HP-UX 11i
es_VE.iso88591 (HP-UX 11i v2
and higher)
es_VE.iso885915 (HP-UX 11i v2
and higher)
es_VE.utf8 (HP-UX 11i v2 and
higher)
Swedish
sv_SE.ISO8859-1
sv_SE.ISO8859-15
sv_SE.iso88591
sv_SE.iso885915@euro
sv_SE.UTF-8
sv_SE.roman8
sv_SE.utf8
Thai
th_TH
th_TH.TACTIS
th_TH.tis620
Turkish
tr_TR.ISO8859-9
tr_TR.iso88599
tr_TR.ISO8859-9@ucs4
tr_TR.turkish8
tr_TR.UTF-8 (Tru64 UNIX
V5.1B only)
Universal
universal.UTF-8
univ.utf8
universal.utf8@ucs4
Supported Locales
E–7
F
System Tuning Information
Developers often find that the general case for which systems are tuned fails to
meet their needs. While it is not the purpose of this guide to provide system tuning
information, we have provided some information on the more common parameters
that are tuned for Tru64 UNIX.
On Tru64 UNIX,you can adjust the default resource limit values with the
dxkerneltuner or sysconfig commands. In order for the new values to take
effect, some parameters require a system reboot, but it is not necessary to rebuild
the kernel.
On HP-UX 11i v1, you can set the tuning parameters with the the kmtune command
or the sam GUI. In order for most changes to take effect, the HP-UX kernel must
be rebuilt and the system rebooted. You can change a few dynamic parameters
(marked “Dynamic” in the table below) without either a kernel rebuild or reboot.
On HP-UX 11i v1.6 and higher, you can change the default values with the
kctune command or the kcweb GUI. In order for the changes to take effect, some
parameters require a reboot, but a kernel build is never required.
For details on any of these options, see the HP-UX 11i reference pages for each
tuning parameter, or consult the online information available at:
http://docs.hp.com
http://www.hp.com/go/tru64docs
The information contained in Table F–1 is based on HP-UX 11i v1 and HP-UX 11i
v2. Detailed tuning information for HP-UX 11i can be found at:
http://docs.hp.com/hpux/onlinedocs/TKP-90202/TKP-90202.html
Table F–1: System Tuning Options
Tru64 UNIX
HP-UX 11i
Dynamic
Description
msg_tql
msgtql
N
Maximum number of
System V IPC messages in
the system at any time.
msg_mni
msgmni
N
Maximum number of
systemwide System V
IPC message queues (IDs)
allowed.
sem_ume
semume
N
Maximum number of
System V IPC undo
entries per process.
sem_msl
semmsl
11i v1.6 +
Maximum number of
System V IPC semaphores
per identifier.
sem_opm
Not Available
System V IPC Message Queue
System V IPC Semaphores
Maximum number of
operations that can be
outstanding on a single
System V semaphore at
one time.
System Tuning Information
F–1
Table F–1: System Tuning Options (cont.)
Tru64 UNIX
HP-UX 11i
Dynamic
Description
shm_seg
shmseg
11i v1.6 +
Maximum number of
System V shared memory
segments per process.
shm_mni
shmmni
Y
Number of System V
shared memory segment
identifiers in the system.
shm_max
shmmax
Y
Maximum size, in bytes,
for a System V shared
memory segment.
max_proc_per_user
maxuproc
Y
Limits the maximum
number of user processes
per user.
max_threads_per_user
max_thread_proc
N
Defines the maximum
number of threads allowed
per process.
per_proc_stack_size
Not Available
max_per_proc_stack_size
maxssiz (32-bit) or
maxssiz_64bit (64-bit)
per_proc_data_size
Not Available
max_per_proc_data_size
maxdsiz (32-bit) or
maxdsiz_64bit (64-bit)
per_proc_address_space
Not Available
Default usable virtual
address space per process.
max_per_proc_address_space
Not Available
Maximum usable virtual
address space per process.
System V Shared Memory
Process and Thread Attributes
The maximum size, in
bytes, of a user process
stack.
Y
Maximum size, in bytes,
of the stack for any user
process.
The maximum size, in
bytes, of a user process
stack.
Y
Maximum size, in bytes, of
the data segment for any
user process.
Kernel Buffer Attributes
bufcache
nbuf (deprecated in
HP-UX 11i v2)
ubc_minpercent
dbc_min_pct
11i v2
The minimum percentage
of memory to be used by
the dynamic buffer cache.
ubc_maxpercent
dbc_max_pct
11i v2
Maximum percentage
of memory for dynamic
buffer cache.
ubc_borrowpercent
Not Available
F–2
System Tuning Information
N
Sets the systemwide
number of file-system
buffer and cache buffer
headers, This parameter
is for backwards
compatibility and should
be set to zero because the
dynamic buffer cache is
preferred.
Percentage of memory
above which the UBC is
only borrowing memory
from the virtual memory
subsystem.
Table F–1: System Tuning Options (cont.)
Tru64 UNIX
HP-UX 11i
Dynamic
Description
Virtual Memory Attributes
maxvas (Version 4.0x only)
Not Available
Maximum Virtual Address
Space
vpagemax (Version 4.0x only)
Not Available
Maximum Protected Pages
mapentries (Version 4.0x only)
Not Available
VM maximum map entries
executable_stack
executable_stack
N
Controls if the stack is
executable (Boolean).
The HP-UX 11i v2 default
is 0. The HP-UX 11i v1
default is 1. The Tru64
UNIX default is 0.
System Tuning Information
F–3
G
Porting Checklist
When filled in, this checklist organizes in one place the answers to many of the
questions related to a porting effort.
•
What is the name of the application to be ported?
•
What is the primary reason for porting the application?
•
In one sentence, describe what the application does:
•
On what operating systems does the current application run? Give specific
versions as reported by the software where you can (examples: Digital UNIX
Version 4.0F, Compaq Tru64 UNIX Version 5.0A, RedHat Linux Version 7.3).
•
To what operating system(s) will the application be ported?
•
List all languages and versions that are used to construct the application
(examples: Compaq C Version 6.2, Perl 5.004, Java 2):
Language
•
Comments
List all layered, proprietary, and third-party products the application depends
on for proper operation (examples: Oracle9i database, OpenGL, Apache):
Product
•
Version
Version
Comments
Do you have all of the source code files required to build the application?
Yes
No
•
What is the quantity of source code? You can specify in terms of lines of code or
megabytes of uncompressed source files.
•
What is the quantity of data associated with this application? Can you
characterize its structure (examples: formatted, in a database, or unformatted
binary)?
•
When was the last time the application environment was completely recompiled
and rebuilt from source?
•
Is the application rebuilt regularly? How frequently?
Porting Checklist
G–1
•
Is the application actively maintained by developers who know it well?
•
How is a new build of the application tested or verified for proper operation?
•
Do you have performance characterization tools to assist with optimization?
•
Will these tests, validation suites, or performance tools need to be ported?
•
Which source-code and configuration management tools are used (examples:
make, SCCS, RCS)?
•
Do you have a development and test environment separate from your
production systems? Yes
•
G–2
No
What procedures are in place for rolling in a new version of the application
into production?
Porting Checklist
H
Source Code for Examples
The source code for the examples in this document are available for download from
the following location:
http://h30097.www3.hp.com/docs/porting/tru64-to-hpux/examples/index.html
Table H–1: Examples
Example Number
Example Name
Files
Example 4–3
Calling Functions without Prototypes
example4-3-1.c
example4-3-2.c
Example 4–5
Passing Types Smaller Than Expected
example4-5-1.c
example4-5-2.c
Example 4–8
Negative Floating Point to Unsigned Integer
Conversion
example4-8.c
Example 4–11
<iostream.h> Replaced By <iostream>
example4-11.C
Example 4–12
Scoping Rules for Variables in a for Statement
example4-12.C
Example 4–13
Template Instantiation with a Pragma Directive example4-13.cxx
Example 4–14
Standard Template Instantiation Syntax
example4-14.cxx
Example 4–15
typename Keyword
example4-15.cxx
Example 4–18
Define Namespace with -Aa Option on HP-UX
11i
example4-18.c
Example 5–1
Uninitialized Global Data
example5-1main.c
example5-1a.c
example5-1b.c
Example 7–1
Creating a Locked Account
example7-1.sh
Example 7–2
Unaligned Data Access
example7-2.c
Example 11–2
Determining Processor Type Using C
example11-2.c
Example 11–3
Number of CPUs Using C
example11-3.c
Example 11–4
Collecting System Information in C
example11-4.c
Example 11–5
Determining the Current CPU
example11-5.c
Example 11–6
Reading the ITC
example11-6.c
Example 11–7
PA-RISC Spinlocks in Assembly Language
example11-7.s
Example 11–8
Spinlock Code for
Example 12–2
Supporting Multiple Byte Orderings Using the
Preprocessor
example12-2.c
Example 12–3
Testing Byte Order
example12-3.c
Example 12–4
Using the htons Routine
example12-4.c
Example 12–5
Using the htonl Routine
example12-5.c
Example 12–6
64-Bit Host To Network Implementation
example12-6.c
Example 12–7
32-Bit Endian Byte Swap Macro
example12-7.c
Example 12–8
64-Bit Endian Byte Swap Macro
example12-8.c
Example 12–9
Direct Byte Access
example12-9.c
Itanium®
Processors
example11-8.s
Source Code for Examples
H–1
Table H–1: Examples (cont.)
Example Number
Example Name
Files
Example 12–10
Named Bit Fields
example12-10.c
Example 12–11
Endianism and Unions
example12-11.c
Example 13–3
Weak Function Binding Using ASM
example13-3.s
Example 13–4
lib1.c Listing
example13-4.c
example13-main.c
Example 13–5
lib2.c Listing
example13-5.c
example13-main.c
Example 13–6
lib3.c Listing
example13-6.c
example13-main.c
H–2
Source Code for Examples
Index
Numbers and Special Characters
32-bit applications
developing, 2–5
64-bit applications
developing, 2–5
64-bit data model
support for, 3–1
A
account management functions, 16–3
ACUCOBOL-GT, 3–4
Acucorp, Inc. COBOL compiler, 3–4
adb, 6–3
ADB debugger, 6–3
address space layout, 5–13
aliases
defining debug aliases, 6–5
Alpha
processor, 11–1
ANSI C
compiler support for, 2–4
compilers, 4–1
ANSI/ISO C++, 4–8
compiler support for, 2–4
application stack, 11–9
applications
developing 32-bit applications, 2–5
developing 64-Bit applications, 2–5
X Window System
( See X Window System )
architecture
endianism, 12–1
archive libraries, 3–5
ASE, 10–1
atomic memory operations, 11–12
authentication functions, 16–3
autosysconfig, 18–1t, 18–2t
Available Server Environment
( See ASE )
building
public domain software, 19–5
building kernel modules, 18–1
byte
size of, 11–2
byte arrays and endian issues, 12–8
byte order
endianism, 12–1
network to host conversion, 12–4
C
C compilers, 2–4, 3–3
options, 4–2
options comparison, A–1
C++ compilers, 2–4, 3–3, 4–8
options comparison, B–1
CAE, 17–1, 17–5
Caliper, 6–5
optimization and profiling tool, 6–7
catalogs
message, 17–5
catgets, 13–4
catopen, 13–4
CDE
( See Common Desktop
Environment )
cfg_configure, 18–2t
cfg_get_state, 18–2t
cfg_query, 18–2t
cfg_unconfigure, 18–2t
change processing security functions,
16–2
character arrays and endian issues,
12–8
characters
complex, 17–5
multibyte, 17–5
wide, 17–5
chatr, 5–26
checklist for porting applications,
G–1
B
+b, 7–2
big endian byte ordering, 12–1
binding
symbol
( See symbol binding )
build environment
XPG4/POSIX compliance, 2–3
child process
tracing, 13–4
cleanup routines
( See fini routines )
clock speed
determining, 11–5
clock_getres()
system timer resolution, 6–6
Index–1
clusters, 10–1
COBOL compiler, 3–4
code optimization, 4–3
code set
converters, 17–4
iconv, 17–4
UTF-16, 17–4
UTF-16BE, 17–4
UTF-16LE, 17–4
UTF-32, 17–4
UTF-32BE, 17–4
UTF-32LE, 17–4
codeset, 17–4
coding practices, 1–3
problematic usages, 2–4
collect, 6–8
command-line options
passing to compilers, 4–2
commands
support for POSIX standard, 2–3
Common Applications Environment
( See CAE )
Common Desktop Environment, 14–2
compile-time instantiation, 4–11
compilers
C compiler options, 4–2
C compilers, 4–1
definition environments, 4–16
floating-point compiler options, 7–8
Fortran, 4–13
Java, 4–12
OpenMP, 9–1
optimization level, 4–3
overview, 3–2
passing command-line options, 4–2
pthread switch, 8–7
typename keyword, 4–12
compiling
OpenGL applications, 14–2
strategies, 2–4
X Window System applications, 14–1
compiling mixed-language programs,
4–15
configure, 19–5
config.guess, 19–5
config.sub, 19–5
converters
code set, 17–4
converting data
between little and big endian systems,
12–2
network to host conversion, 12–4
CPU
determining, 11–3
determining how many, 11–4
determining speed, 11–5
CPUID register, 11–3
curses, 17–5
Index–2
D
data conversion
between little and big endian systems,
12–2
network to host conversion, 12–4
data processing security functions,
16–2
dbx debugger, 6–3
DCPI, 6–5, 6–7
debugging
defining aliases, 6–5
location of debug information, 6–4
MPI, 9–4
profiling tools, 6–6
system timers, 6–6
threads debugging tools, 8–9
tools, 2–6, 6–3
definition environments
controlling, 4–16
determining
processor version, 11–3
developer support
resources, 3–7
direct loader access, 5–25
directives for mixed-language calls,
4–15
directory permissions
system defaults, 7–4
DLD_VERBOSE_ERR, 5–24
DLKM, 18–1
APIs, 18–1t
dlopen
( See dynamic loading )
tls, 13–9
documentation resources, 20–1
dynamic library loading, 13–6
Dynamic Loadable Kernel Modules
( See DLKM )
dynamic loading, 5–11
dynamically linked libraries, 3–5
E
elfdump, 5–27
EMANATE, 15–1
endfsent, 13–6
endian
differences, 17–1
endianism, 12–1
environment variables, 7–1
loader run-time options, 5–24
examples, H–1
exception handling
floating-point, 7–7
execution order
init/fini routines, 13–13
F
header files
location of, 3–5
POSIX thread header files, 8–7
hex constants and endian issues,
-fast option
compiler options, 4–3
file system
APIs, 13–6
finalization routines
12–8
high availability, 10–1
scripts, 10–8t
hiprof, 6–5, 6–7
host to network data conversion,
( See fini routines )
fini routines, 13–12
execution order of, 13–13
usage, 13–13
floating-point
compiler options for, 7–8
exception handling for, 7–7
hardware support for, 11–9
resources, 11–15
floating-point hardware, 11–9
Fortran compilers, 3–4, 4–13
linking mixed-language programs,
12–4
HP aC++, 4–8
HP C/ANSI C Developer’s Bundle, 3–3
HP Caliper
analyzing multithreaded application
performance, 8–10
HP Glance
performance analysis tool, 6–12
HP OpenView, 15–1
_HP_DLDOPTS, 5–24, 7–1
4–15
mixed-language programming, 4–15
options comparison, C–1
freeware, 19–1
I
I18N
( See internationalization )
G
ILP32, 2–5
gcc
( See GNU,cc )
gdb debugger , 2–6
getfsent, 13–6
getfsfile, 13–6
getfsspec, 13–6
getfstype, 13–6
getmntent, 13–6
gettxt, 13–4
glance
( See HP Glance )
global data
uninitialized, 5–7
gmake
( See GNU,make )
GNU, 19–5
cc, 6–3, 19–3t
compiler
( See GNU,cc )
configure, 19–5
debugger, 6–3, 6–5
make, 19–4t
gprof, 6–5, 6–6, 6–7
H
+h, 13–10
halfword
size of, 11–2
hardware floating-point, 11–9
( See also Truncated Address Space
Objects )
image modification
( See chatr )
include files
location of, 3–5
OpenGL required files, 14–2
X Window System required files, 14–1
industry standards, 3–1
information resources, 20–1
init routines, 13–12
execution order of, 13–13
usage, 13–13
initialization routines
( See init routines )
Instruction Pointer
( See IP )
internationalization, 13–4, 13–6,
17–1
( See also localization )
iostat, 6–8
system profiling tool, 6–10
IP, 11–7
IP32, 2–5
( See also Truncated Address Space
Objects )
Itanium
processor, 11–1
resources, 11–15
Index–3
J
Java, 4–12
Java compiler, 3–3
Java tuning, 4–13
JIT, 4–12
K
K&R source code
C compatible mode, 2–4
calling functions without prototypes,
4–4
passing types smaller than expected,
4–5
kdbx debugger, 6–3
kernel buffer attributes
tuning, F–1
kernel modules, 18–1
kernel-intrusive functions
porting difficulties, 2–4
L
L10N
( See localization )
Ladebug debugger, 2–6, 6–3
language mode options
compiler, 4–1
ld
( See link,editor )
LD_BIND_NOW, 5–24
LD_LIBRARY_PATH, 5–11, 5–28, 7–1
LD_PRELOAD, 7–1
ldd, 5–26
LDOPTS, 5–2
libraries, 13–10
( See also shared libraries )
dynamic loading of, 13–6
location of, 3–5
OpenGL required libraries, 14–3
resolution of by linker, 5–11
thread-safe libraries, 8–8
X Window required libraries, 14–1
link
editor, 5–1
linker, 11–12
defined symbols, 5–4
options comparison, D–1
recommended options, 5–28
related tools, 5–26
resources, 5–29
run-time
( See loader )
uninitialized global data, 5–7
weak symbol support, 5–7
weak symbols, 13–11
linking
Index–4
OpenGL applications, 14–2
X Window System applications, 14–1
linking libraries, 3–5
linking mixed-language programs,
4–15
little endian byte ordering, 12–1
loadable kernel modules, 18–2
loadable kernel subsystems, 18–1
APIs, 18–1t
loader, 5–11
APIs, 5–25
dynamic library loading, 13–6
environment variables, 5–24, 7–1
library resolution, 5–11
options, 5–24
locale, 17–4
locales, 17–4
localization, 13–4, 17–1, 17–4, 17–5
curses, 17–5
error messages, 13–6
messages, 17–5
longword
size of, 11–2
LP64, 2–5
LP64 64-bit data model
support for, 3–1
LPATH, 5–3, 7–2
lpthread compiler switch, 8–7
lsof
system profiling tool, 6–12
M
mail lists, 20–3
make command, 6–1
options, 6–2
rules, 6–2
XPG4/POSIX compliance, 2–3
makefiles, 6–1
malloc, 13–3
memory
atomic memory operations, 11–12
management, 13–3
mapped, 13–3
shared, 13–3
tuning virtual memory attributes, F–1
memory leak debugging, 6–7
message catalogs, 17–5
message passing interface
( See MPI )
message queues
tuning System V IPC message queues,
F–1
messages
catalogs, 13–4
error, 13–6
localization, 17–5
mixed-language programming, 4–15
compiling, 4–15
directives for calls, 4–15
linking, 4–15
mmap, 13–3
Motif, 17–1
MPI, 9–2
debugging, 9–4
HP MPI commands, 9–4
resources, 9–7
multiword entities
initializing, 12–7
N
netstat, 6–8
system profiling tool, 6–11
network to host data conversion,
12–4
news group resources, 20–2
NULL, 13–3
dereference, 13–4
NUXI
endianism, 12–2
O
octaword
size of, 11–2
odump, 5–27
open source software, 19–1
Open Source Software Collection,
19–1, 19–3
OPEN3D, 14–2
OpenGL, 14–1, 14–2
include files, 14–2
OpenMP, 9–1
OpenView, 15–1
optimization level
compiler optimization, 4–3
optimization tools
Caliper, 6–7
Prospect, 6–6
options comparison
C compilers, A–1
C++ compilers, B–1
Fortran compilers, C–1
linker, D–1
OSCC, 19–3
P
PA-RISC
processor, 11–1
packaging
RPM, 2–7
software distribution, 2–7
pagesize, 11–12
PAM, 16–2
comparison with SIA, 16–3
security functions, 16–3
patches
obtaining, 3–6
patching and patch-related
commands
resources, 3–7
PC, 11–7
performance analysis tools
Caliper, 6–7
HP Glance, 6–12
Prospect, 6–6
persistent data, 12–2
preprocessor controlled byte order,
12–3
run-time byte order control, 12–3
pixel depth
X Window System applications, 14–2
pixie, 6–5, 6–7
Pluggable Authentication Modules
( See PAM )
porting, 1–1
services, 1–3
porting checklist, G–1
POSIX
commands and utilities, 2–3
support for standard, 3–1
POSIX thread header files, 8–7
POSIX threads, 8–1
postlink image modification
( See chatr )
PowerStorm, 14–2
pragma
UNALIGN, 7–7
pragmas
pragma instantiation directives, 4–11
precedence
symbol precedence, 5–23
preprocessor controlled byte order,
12–3
process attributes
tuning, F–1
processor
Alpha, 11–1
determining, 11–3
determining current, 11–6
Itanium, 11–1
PA-RISC, 11–1, 11–2
set APIs, 9–6
set commands, 9–5
processor set commands, 9–5
prof, 6–5, 6–6
profiling
MPI, 9–4
profiling tools, 6–5, 6–8
Index–5
( See also system profiling tools )
Caliper, 6–5, 6–7
DCPI, 6–5, 6–7
gprof, 6–5, 6–6, 6–7
hiprof, 6–5, 6–7
pixie, 6–5, 6–7
prof, 6–5, 6–6
Prospect, 6–6
Spike, 6–5
Third Degree, 6–5
Program Counter
( See PC )
Prospect
optimization and profiling tool, 6–6
ps
system profiling tool, 6–10
PseudoColor
X Window System applications, 14–2
pthread compiler switch, 8–7
ptrace, 13–4
public domain software, 19–1
Q
S
sar
system profiling tool, 6–10
scheduling threads, 8–4
scripts
cluster high availability scripts, 10–8t
SD
( See Software Distributor )
security
migrating from SIA to PAM, 16–1
security functions
provided by PAM, 16–3
provided by SIA, 16–1
Security Integration Architecture
( See SIA )
Segmentation Fault
( See SEGV )
SEGV, 13–4
semaphores
tuning System V IPC semaphores, F–1
Serviceguard, 10–1
session processing security functions,
16–2
q4 debugger, 6–3
quadword
size of, 11–2
R
register stack, 11–9
resolution
symbol
( See symbol resolution )
resources, 20–1
developer support, 3–7
floating-point information, 11–15
Itanium, 11–15
linker, 5–29
mail lists, 20–3
MPI, 9–7
patching and patch-related commands,
3–7
STREAMS and sockets, 15–9
threads, 8–11
rld
( See loader )
_RLD_ARGS, 5–24, 7–1
_RLD_LIST, 7–1
_RLD_ROOT, 5–11, 7–1
rpath, 5–11, 5–12, 7–2
+rpathfirst, 5–12
RPM, 2–7
RSE, 11–9
run-time byte order control, 12–3
run-time limits, 7–3
run-time linking
( See loader )
Index–6
setcat, 13–4
setfsent, 13–6
shared libraries, 3–5
debugging, 6–4
multithreaded environments and, 8–7
versioning, 13–10
shared memory, 13–3
tuning System V shared memory, F–1
shared memory parallelism
OpenMP, 9–1
SHLIB_PATH, 5–12, 7–1
shmget, 13–3
SIA, 16–1
change processing functions, 16–2
comparison with PAM, 16–3
data processing functions, 16–2
library functions, 16–1
session processing functions, 16–2
Simple Network Management
Protocol
( See SNMP )
SNMP, 15–1
sockets
API, 15–1
resources, 15–9
Software Distributor, 2–7
Software Package Builder, 2–7
software resources, 20–1
software version, 1–2
-soname, 13–10
sourceconfig, 18–1t, 18–2t
SP, 11–9
SPB
( See Software Package Builder )
Spike, 6–5
stack pointer
( See SP )
standards, 3–1
POSIX, 3–1
System V, 3–1
X/Open, 3–1
statically linked libraries, 3–5
strcmp, 13–4
STREAMS
API, 15–7
resources, 15–9
strerror, 13–6
string
functions, 13–4
strings, 13–4
SuperPages, 11–12
support
for developers, 1–3
support resources, 20–1
SVID
functions, 3–1
symbol binding, 5–23
deferred, 5–23
immediate, 5–23
lazy
( See symbol binding, deferred )
nonfatal, 5–23
restricted, 5–23
symbolic, 5–23
symbol precedence, 5–23
symbol resolution, 5–21
breadth-first, 5–21
depth-first, 5–22
symbols
linker support for weak symbols, 13–11
linker-defined symbols, 5–4
loader resolution of, 5–11
synchronization of threads, 8–6
sys_errlist, 13–6
sys_nerr, 13–6
sysconfig, 18–1t
sysconfigdb, 18–1t, 18–2t
system libraries
( See libraries )
system profiling tool
iostat, 6–10
netstat, 6–11
ps, 6–10
sar, 6–10
top, 6–8
vmstat, 6–9
system profiling tools, 6–8
( See also profiling tools )
collect, 6–8
iostat, 6–8
netstat, 6–8
system timers, 6–6
System V
support for standard, 3–1
System V Interface Definition
( See SVID )
T
TASO
( See Truncated Address Space
Objects )
template instantiation, 4–11
Third Degree, 6–5
third-party software
availability of, 2–3
thread
local storage, 13–9
thread attributes
tuning, F–1
Thread Local Storage
( See TLS )
threads
analyzing multithreaded application
performance, 8–10
compiling multithreaded applications,
8–7
debugging, 8–9
header files, 8–7
POSIX 1003.1c interfaces, 8–1
proprietary threads, 8–2
pthread compiler switch, 8–7
resources, 8–11
scheduling, 8–4
synchronizing, 8–6
thread-safe libraries, 8–8
TLS, 8–8
timer_*
system timer functions, 6–6
TLS, 8–8, 13–9
top
system profiling tool, 6–8
tracing
child process, 13–4
Tru64 UNIX software version, 1–2
TruCluster Server software, 10–1
TruColor
X Window System applications, 14–2
Truncated Address Space Objects,
2–5
tuning
MPI, 9–4
system tuning, F–1
typename keyword, 4–12
Index–7
U
W
UCS-2
( See UTF-16 )
UCS-4
( See UTF-32 )
umask settings, 7–4
UNALIGN, 7–7
uname, 13–5
Unicode, 17–1
uninitialized global data, 5–7
union
wait, 13–5
unions and endianism, 12–7
updates
obtaining patches, 3–6
usage of init/fini routines, 13–13
user authentication functions, 16–3
UTF-16, 17–1
UTF-32, 17–1
UTF-8, 17–1
utilities
support for POSIX standard, 2–3
V
version
software, 1–2
versioning
intralibrary, 13–10
library-level, 13–10
vfork, 13–4
virtual memory attributes
tuning, F–1
Visual Class
X Window System applications, 14–2
Visual Threads
analyzing multithreaded application
performance, 8–10
vmstat
system profiling tool, 6–9
Index–8
wait
union, 13–5
wait3, 13–5
wait4, 13–5
WDB debugger, 2–6, 6–3
weak symbol support, 5–7
wide-character, 17–5
word
size of, 11–2
X
X
( See X Window System )
Version 11
( See X Window System )
X Window System, 14–1
applications, 14–2
CDE, 14–2
compiling applications, 14–1
Display, 14–2
localization, 17–5
PseudoColor, 14–2
RootWindow, 14–2
TrueColor, 14–2
Visual Class, 14–2
X/Open
support for standard, 3–1
X11
( See X Window System )
X11R5, 14–1
X11R6, 14–1
Xt, 17–1, 17–5
Z
Zero Page, 13–4
Tru64 UNIX Documentation Reader’s
Comments
HP welcomes your comments and suggestions on this guide. Your input will help
us to write documentation that meets your needs. Please send your suggestions to:
[email protected]
Please be sure you include the following information:
Name of the document:
Tru64 UNIX to HP-UX 11i Porting Guide
Page number(s):
Product name and version:
Please rate the guide:
Excellent
Good
Fair
Poor
Accuracy (software works as manual
says)
Completeness (enough information)
Clarity (easy to understand)
Organization (structure of subject
matter)
Figures (useful)
Examples (useful)
Index (ability to find topic)
Usability (ability to access
information quickly)
Tru64 UNIX Documentation Reader’s Comments
xxi
Please list errors you have found in the manual:
Page
Description
Additional comments or suggestions to improve the manual:
Name/Title
Dept.
Company
Date
Mailing Address
Mailing Address
(cont.)
Phone
Email
xxii
Tru64 UNIX Documentation Reader’s Comments
">