| United States-English |
|
|
|
![]() |
HP aC++ Version A.03.13 Release Notes: HP Series 9000 > Chapter 4 Problem Descriptions and Fixes and Known LimitationsKnown Problems |
|
Customers on support can use the product number to assist them in finding SSB and SRB reports for HP aC++. The product number you can search for is B3910BA. To verify the product number and version for your HP aC++ compiler, execute the following HP-UX commands:
Following are known problems and workarounds. At the HP-UX 11.00 release, the math.h header file has changed in the following ways:
If you see a message like the following, you may be using a non-current version of the HP aC++ run-time support library.
For example, if you are a library distributor, you must ensure that your customers use the same or a newer version of the libCsup run-time library as you. If necessary, you should install the most current HP aC++ library support patch and distribute this patch to your customers. If you use explicit instantiation instead of closing a library, and you compile with the +inst_auto option, then unless you compile with the +inst_none option, unsatisfied symbols will be generated for inline template functions that are too large to inline. The underlying type corresponding to the "size_t" typedef has changed from unsigned int to unsigned long. Similarly, "ptrdiff_t " has changed from int to long. These changes make the 10.10, 10.20 HP aC++ runtime libraries incompatible with subsequent compiler releases. The changes will cause compatibility problems when size_t is used in a non-extern "C" interface. (The mangled signature would be different.) Due to these changes, if any object files are recompiled or linked, then all HP aC++ files must be recompiled. This implies that third party libraries in archive form also need to be recompiled or resupplied. When your code overloads system header file functions, it is possible that C++ source files that compile without error using HP aC++ for HP-UX 10.10 or 10.20 might not compile with a subsequent compiler release. The example below shows why this potential problem exists.
ff is overloaded to take either a time_t, long, or char parameter. On a 10.10 or 10.20 system where time_t is a long, the call to ff in main resolves to ff(time_t). On a 10.30 system, however, where time_t is an int, the code fails to compile:
An application that ran on the HP-UX 11.00 release will generally continue to run with the same behavior on 32-bit and 64-bit HP-UX 11.00 9812 EXTPAK provided that any dependent shared libraries are also present. An executable is a binary file that has been processed by the HP linker with ld or indirectly with the compiler, and can be run by the HP-UX loader(exec). The following items describe exceptions to binary compatibility between the 11.00 and 9812 EXTPAK releases. These conditions can occur during your development process, but rarely affect deployed applications. Under the following conditions, when you compile your source code without any changes (to source code, options, or makefiles), you create relocatable object files or executables that cannot be moved back to an 11.00 system.
When you make changes to your source code, options, or makefiles to use new features of the 9812 EXTPAK release, you may introduce the following areas of binary incompatibility. You can apply patches to the 11.00 release to accommodate the relocatable object file or executable on an 11.00 release for backward compatibility.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||