Compatibility Statement for HP-UX 11.0

Hewlett-Packard has a long record of providing HP-UX compatibility. This feature protects your investment and allows you to easily upgrade your systems. HP has always recognized that HP-UX compatibility is an important feature that HP customers demand.

Compatibility requirements span across HP-UX products to third party products as well. All third party products (and products the third party products call) are equally important components in the complete customer environment. Customer solutions often have complex, multiple chains of dependent applications spanning the entire range of HP-UX products as well as third party products. One broken link in the chain of dependencies may result in an application that no longer works. The unbroken string of compatibility support on HP-UX is one of the biggest and best benefits provided by HP.

HP-UX supports forward compatibility from pre-11.0 to 11.0. This chapter will describe what this means for executable applications, object files, source files, data, and libraries, and will also discuss compatibility exceptions.

HP-UX supports the following types of compatibility in HP-UX 11.0:

binary compatibility
source compatibility
data compatibilty
upgrade compatibility
relocatable binary compatibility

Binary Compatibility

An application that ran on an HP-UX 10.x release will generally continue to run with the same behavior on 32-bit and 64-bit HP-UX 11.0 provided that any dependent shared libraries are also present. An executable is a binary file that has been processed by the HP link editor with ld or indirectly with the compiler, and can be run by the HP-UX loader (exec).

Source Compatibility

32-bit software that compiled on an HP-UX 10.x release can be recompiled without change on HP-UX 11.0. The term "source" includes input source to compilers, scripts, and makefiles.

Data Compatibility

A 32-bit application can continue to access persistent data files, such as system files, backup/recovery formats, and HP-documented data formats via supported APIs in the same manner as the previous release. A 64-bit application can access the same data in the same manner as a 32-bit application. For example, if you access the password file information via getpwent() rather than directly reading the file, your application will maintain data compatibility.

Upgrade Compatibility

Customized configurations and data from HP-UX 10.x are preserved upon installation/upgrade to 32-bit or 64-bit HP-UX 11.0.

Relocatable Binary Compatibility

A relocatable object can be a file (.o), shared library (.sl), or an archive library (.a).

Several types of object binary compatibility are included here:

Release-to-release relocatable object binary compatibility - an executable created by linking with forward-compatible, relocatable objects from different releases or using shl_load()/dlopen() to dynamically load shared libraries built on a different release than the application is NOT SUPPORTED.
For example, this can occur when you recompile your components on HP-UX 11.0, but link with ISV libraries that were created for HP-UX 10.x. This means that if one object is recompiled on 11.0, all objects that comprise the executable must be recompiled on 11.0; you cannot link both pre-11.0 libraries and 11.0 libraries in one relocatable object/executable. Note that you will not see warning messages if you do this; but the executable may exhibit incorrect behavior.
Archive and shared relocatable object compatibility - an executable created by linking with a mixture of shared and archive libraries. Link restrictions are described in a following section. NOT RECOMMENDED.
Data model relocatable object compatibility - an executable created by linking with a mixture of 32-bit and 64-bit objects. NOT SUPPORTED. The loader will not permit this.

For detailed information see the following two documents:

HP-UX 11.0 Software Developer's Guide
This white paper addresses various features and benefits of moving applications to HP-UX 11.0. See /usr/share/doc/11dev.ps or http://docs.hp.com/hpux/os.
HP-UX 64-bit Porting and Transition Guide
This guide describes the changes you need to make to compile, link and run programs on a 64-bit operating system. See /opt/ansic/newconfig/RelNotes/64bitTrans.bk.ps, /opt/aCC/newconfig/TechDocs/64bitTrans.bk.ps, or http://docs.hp.com/hpux/os.

HP-UX 10.x Applications on HP-UX 11.0

HP-UX 11.0 provides compatibility for the great majority of applications that compile and run on HP-UX 10.x releases. Most applications will be source compatible for both 32-bit and 64-bit HP-UX 11.0. For binary compatibility, most 32-bit applications will run on 32-bit HP-UX 11.0. 32-bit applications will also run on 64-bit HP-UX 11.0, with a few exceptions.




	NOTE: You do not have to port most software to run it on HP-UX 11.0. The majority of 10.x software will run acceptably on 11.0 without source changes or recompilation.

To determine if a specific 32-bit application is binary compatible on a 64-bit operating system, you can do the following:

If you have purchased a third-party application:
Check with the application vendor to ensure that the application is supported on HP-UX 11.0. If you will be running the 64-bit version of 11.0, ask the vendor for a statement regarding 64-bit application interoperability with 32-bit applications.
If you have locally-written software:
See the HP-UX 11.0 Software Transition Kit (STK) for detailed information on how to ensure that your code is compatible on HP-UX 11.0. The HP-UX STK is available on the HP-UX 11.0 Application Release CD-ROM, or via the World-Wide Web at http://www.software.hp.com/products/IA64/index.html.

Moving a 9.x Application to 11.0

If you are transitioning a 9.x application to 11.0, you DO NOT need to transition your 9.x application to 10.x and test it on 10.x prior to transitioning it to 11.0.

You should transition your application directly to 11.0. Note that your application will be affected by any compatibility issues that occurred in 9.x and 10.x, as compatibility issues are generally cumulative. One issue that may impact your 9.x application is the 10.x file system layout. Please refer to the 10.x Release Notes for further details on this issue.

Compatibility Support and Status

In general, compatibility is supported where the application is well-behaved and follows good programming practices. Good programming practices include using only documented Application Programming Interfaces (APIs), including the required header files, avoiding architecture-specific knowledge, and avoiding APIs that have portability and compatibility issues.

Changes to the syntax or semantics of APIs are avoided where possible. Unfortunately, compatibility is sometimes compromised in order to comply with new standards, add new features, and enhance performance. In most cases, these changes can be implemented in a way that maintains compatibility. In extreme cases, changes are mandated by a standard that compromises compatibility.

Compatibility of Non-HP Products

Compatibility can also be affected by the compatibility support of end-user or Independent Software Vendor (ISV) products, such as third party compiler products. HP can influence the compatibility of the products that HP provides, but has no control over the compatibility support of others products.

Obsolescence

APIs can be removed from HP-UX after adhering to a recommended phased obsolescence plan. Interfaces that are to be obsoleted are clearly identified in HP documentation at least one release prior to obsolescence. Applications that use these obsoleted interfaces may not run after support has been discontinued or removed.

Link Restrictions

Be aware of the type of libraries (shared or archive) linked to an application. The way in which the libraries are linked can affect binary compatibility. The application should not be linked with shared libraries that have dependencies on archive HP-UX system libraries. Instead, the application should use the shared versions of these libraries where they exist. See "Coding Practices that Impact Compatibility" below for more information.

Library providers cannot include HP-supplied libraries inside their own library. Applications and libraries cannot explicitly load HP-supplied shared libraries with shl_*() APIs.

Lastly, applications do not need to include -lc on the C compile line. The C compiler driver automatically includes the C library during the link phase. Shared libraries must not establish explicit dependencies with libc via -lc.

Using New Features

In general, usage of new release features will minimally require a recompile and perhaps source code changes. For example, you will need to recode and recompile to take advantage of 11.0 kernel threads.

In order to take advantage of 64-bit large address space and large memory in 11.0, an application must minimally recompile, make makefile changes, and may require source code changes to remove 32-bit limitations from the code. See the HP-UX 11.0 Software Transition Kit or HP-UX 64-bit Porting and Transition Guide for more information. (See /opt/ansic/newconfig/RelNotes/64bitTrans.bk.ps, /opt/aCC/newconfig/TechDocs/64bitTrans.bk.ps, or the Instant Information CD-ROM.) Applications wanting to take advantage of kernel threads will also need to make source and makefile changes.

Compatibility Exceptions in 11.0

There are a few compatibility exceptions in 11.0; most of these exceptions are primarily corner cases with a small impact. Here are some highlights that can be readily detected in C/C++ sources with the HP-UX 11.0 Software Transition Kit source scanner tools. For the complete list and further details on specific exceptions, see the impacts found by the HP-UX 11.0 STK source scanner. See “Transition Tools” in Chapter 2 for more information.

Binary Compatibility Exceptions

fsmount() no longer supports NFS; use nfs_mount() instead.
stat*() APIs can no longer be used to determine the file system type; use getfstype() instead.
uname -m on the V-Class -- model names more than 8 bytes are truncated; use getconf instead.
10.x archive applications which use the database enumeration APIs may not work correctly on NIS+ converted systems.
ARG_MAX is increased from 2K in 10.20 to 20K in 11.0. Applications that allocated buffers of ARG_MAX may fail when there is more than 20K in the environment.

Source Compatibility Exceptions

Xcurses APIs changed to adhere to the XPG4.2 standard
Year 2000 support -- the old behavior was for two-digit year to map to the system clock. The Year 2000-safe behavior is to map 00-68 to 2000-2068 and 69-99 to 1969-1999.
ANSI C is the default C compiler behavior as opposed to K&R compatible C.
API obsolescence in libc, libm, and libportnls.
PAGE_SIZE/PAGESIZE symbols have been removed to adhere to standards since HP-UX supports variable page size (POPS); use sysconf() instead.
Architecture dependencies (runtime architecture)
New features will need code changes to enable the new functionality in an application:
- Kernel threads
- Year 2000 safe and large dates beyond the Year 2038 to encode the number of seconds since 1970
- Transition from Cfront to ANSI C++ and from F77 to Fortran90
- 64-bit applications and 64-bit applications interoperating with 32-bit applications
- 64-bit ELF support for applications that are dependent on object file format, debug/unwind format
- OOCOBOL (Object Oriented COBOL)
- 32-bit pstat() applications which will be run on the 64-bit OS. 9 fields can overflow to 64-bit on the 64-bit OS. Use the __PSTAT64 wrappers.

Relocatable Object Code Compatibility Exceptions

The following types of objects cannot be combined in one executable:

+Oparallel with non-+Oparallel
Year 2000 with non-Year 2000 (getdate(), strptime(), and dependent APIs)
The POSIX.1c compliant APIs are provided in libpthread. Linking libdce/libcma and libpthread in the same application will result in incorrect application behavior.
ONC/NFS RPC APIs (svctpc_create(), svcudp_bufcreate(), ...) objects from 11.0 and pre-11.0, due to a change in the underlying implementation from sockets to streams in 11.0.
Large file APIs and standard file APIs with the same file stream (since 10.10)
UNIX95 and non-UNIX-95 in certain circumstances (since 10.10)

Makefile Changes (When Recompiling)

Database enumeration APIs (i.e. getpwent(), getgrent(), ...) in libc and libsec have a new dependency on libdld.sl shl_load()/dlopen() to load the appropriate service for NIS, NIS+, DNS, and the direct file.
Some libc APIs were moved to libm or libnsl due to standards/de facto standards and will require a link line change to find the APIs in the new library.