Known 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:

what /opt/aCC/lbin/ctcom
 
what /opt/aCC/bin/aCC

To verify the product number and version for the linker:

what /usr/ccs/bin/ld

To verify the product number and version for the shared library loader:

what /usr/lib/dld.sl




	NOTE: Your system, if correctly installed, should have a symbolic link from /usr/lib/aCC/dld.sl to /usr/lib/dld.sl

Following are known problems and workarounds.

Incompatibilities Between the Standard C++ Library and the Draft Standard

As the ISO/ANSI C++ standard has evolved over time, the Standard C++ Library has not always kept up. Such is the case for the "times" function object in the functional header file. In the standard, "times" has been renamed to "multiplies."

If you want to use "multiplies" in your code, to be compatible with the ISO/ANSI C++ standard, use a conditional compilation flag on the aCC command line.

For example, for the following program, compile with the command line:

aCC -D__HPACC_USING_MULTIPLIES_IN_FUNCTIONAL test.c

// test.c
int times;                   //user defined variable
#include <functional>
// multiplies can be used in

int main() {}
// end of test.c

Depending on the existence of the conditional compilation flag, functional defines either "times", or "multiplies", not both.

So, if you have old source that uses "times" in header functional and also new source that uses "multiplies", the sources cannot be mixed. Mixing the two sources would constitute a non-conforming program, and the old and new sources may or may not link.

If your code uses the old name "times," and you want to continue to use the now non-standard "times" function object, you do not need to do anything to compile the old source.

Unsatisfied Symbols if Using Non-current Run-time Support Library

If you see a message like the following, you may be using a non-current version of the HP aC++ run-time support library.

/opt/aCC/lbin/ld: Unsatisfied symbols:
   Class tables [Vtable] dependent on key function:
   "__versioned_type_info::~__versioned_type_info()" (data)

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.As of the date of these release notes, the most current library support patch number is: PHSS_17872

Unsatisfied Symbols for Inline Template Functions

If you use explicit instantiation instead of closing a library, and you compile with the +inst_auto option, then unsatisfied symbols will be generated for inline template functions that are too large to inline.

Syntax Errors when Using /usr/include/sys/time.h

If you see the following error message, it means that CLOCKS_PER_SEC is not defined:
Error 171: "7198.C", line 2 # Undeclared variable 'CLOCKS_PER_SEC'. int i = CLOCKS_PER_SEC; ^^^^^^^^^^^^^^^^
To correct the problem, you can install the appropriate patch listed below (or any successor patch) or implement the workaround described below:
PHKL_8691 series 700 HP-UX 10.10 PHKL_8692 series 800 PHKL_8693 series 700 HP-UX 10.20 PHKL_8694 series 800
The workaround is to modify the /usr/include/sys/time.h file as follows:
1. Find the first occurence of:
  #endif /* _INCLUDE__STDC__ */
2. Immediately before the first occurence of the above line, add the following code, replacing SomeValue with the value you need (1000000 would be the system default):
  #else #ifdef __cplusplus #define CLOCKS.PER_SEC SomeValue #endif
The /usr/include/sys/time.h file contains a K & R style function declaration for which HP aC++ generates an error like the following:
Error 43: "/usr/include/sys/time.h", line 487 # C++ does not allow Old-style (non-prototype) function definitions.
To workaround, whenever time.h is included by a source program, you can define the __STDC__ macro on your command-line, as in the following example:
aCC -D__STDC__
HP aC++ generatres an error like the following stating that structs or any types cannot be declared extern.
Error 608: "/usr/include/sys/time.h", line ??? # Types may not be declared static, auto, register, extern or mutable. extern struct sigevent; ^^^^^^^^^^^^^^^^^^^^^^
The error is caused by a problem in the /usr/include/sys/time.h file. To workaround, you can change the line extern struct sigevent; in the time.h file to:
struct sigevent;
Or you can install the appropriate patch listed below:
PHKL_8693 series 700 HP-UX 10.20 PHKL_8694 series 800

Syntax Problems when Using /usr/include/math.h

To resolve a conflict between the exception struct in /usr/include/sys/math.h and the aC++ exception struct, you can install the appropriate patch, currently PHCO_14645 (or any successor patch). Alternatively, you can implement the workaround described below.

The workaround is to modify the /usr/include/math.h file as follows:

Find the line:
#define _MATH_INCLUDED
Immediately following the above line, add the next line:
#define exception math_exception
Find the line:
#endif /* _MATH_INCLUDED */
Immediately before the above line, add this line:
#undef exception

Warnings when using /usr/include/rpc/xdr.h

Compile-time warnings like the following should be ignored. They are caused by an incorrect prototype in the /usr/include/rpc/xdr.h file.

Warning 301: "/YourFileName/usr/include/rpc/xdr.h", line 276 # The
(...) parameter list is a non-portable feature.
extern bool_t xdrrec_eof(__o);      /* true iff no more input */




	NOTE: Warning 302 is now a suggestion and only occurs with the +w option.

Binary Compatibility

An application that ran on previous HP-UX 10.x releases (10.01, 10.10, or 10.20) will generally continue to run with the same behavior with this 10.20-based HP aC++ release 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 previous 10.20 and current releases. These conditions can occur during your development process, but rarely affect deployed applications.

Binary Incompatibilities without Changes

Under the following conditions, when you compile your source code without any changes (to source code, options, or makefiles), you can create relocatable object files or executables that cannot be moved back to a previous 10.x system.

Instrumented code with PBO or +O4 optimization
If you use PBO (+I compiler or linker option) or the +O4 option during development and recompile with your current compiler, you may create instrumented objects (ISOM) that a previous system does not recognize.
NOTE: This code may not be backward-compatible with previous 10.x releases. In general, you cannot move instrumented object files backward.
If you move an ISOM across operating system versions, for example, from an 11.x system to a 10.x system, you may receive the following error:
Error at line 0: Backend Assert ** Ucode versions earlier then v.4 no longer supported. (5172)

Binary Incompatibilities with Changes

When you make changes to your source code, options, or makefiles to use new features of the current release, you can introduce the following area of binary incompatibility.

Open Graphics Library (OGL) Support
This release provides OGL support to improve performance. If you make changes to your source code to recompile using the OGL headers, you receive the message "invalid fixup" when you link your relocatable object file or run your executable on a previous 10.x system. .