Binary compatibility

C objects

C objects that are built with Open XL C/C++ for z/OS® are generally binary compatible with those that are built with z/OS XL C/C++ unless otherwise noted in this section.

C++ objects

You need to recompile your z/OS XL C/C++ programs with Open XL C/C++ for z/OS.

Alignment of pthread_t type

The alignment of the pthread_t type is different in z/OS XL C/C++ 2.4.1 than in Open XL C/C++ for z/OS or z/OS XL C/C++ 2.4 or previous releases, which causes a potential binary compatibility issue when mixing C or C++ objects that are compiled with Open XL C/C++ for z/OS and z/OS XL C/C++ 2.4.1.

In z/OS XL C/C++ 2.4 and Open XL C/C++ for z/OS, the alignment of the pthread_t type is the same as char. However, in z/OS XL C/C++ 2.4.1, the alignment of pthread_t is the same as long int in 64-bit mode. The size of the type is the same so almost all code is compatible. The difference in alignment results in a binary compatibility issue if the code has structures or unions that contain members of type pthread_t. For example:

struct S1 {
  pthread_t t;
  char c;
};

In z/OS XL C/C++ 2.4.1, the size of the structure S1 is two long int including the padding due to alignment and have the alignment of a long int.

In z/OS XL C/C++ 2.4 or previous releases and Open XL C/C++ for z/OS, the structure S1 has the size of a long int plus a char and have the alignment of a char.

struct S2 {
  pthread_t t;
  long int n;
};

This alignment difference does not affect programs that create variables or parameters of type pthread_t unless the change in alignment of pthread_t causes a structure or union to change alignment or size. In this case, you can do either of the following:

• It is recommended to add __attribute__((align(8))) to the pthread_t member for the Open XL C/C++ for z/OS compilation. Alternatively, you can add __attribute__((packed, align(1))) to the pthread_t member for the z/OS XL C/C++ 2.4.1 compilation.
• Recompile all of the programs with Open XL C/C++ for z/OS.

Alignment for _Atomic() and std::atomic<>

In Open XL C/C++ 1.1 for z/OS, the alignment of the _Atomic type specifier is limited to 8 bytes.

In Open XL C/C++ 2.1 for z/OS, the maximum alignment is 16 bytes.

You need to recompile your program with Open XL C/C++ 2.1 for z/OS.

chrono::file_system_clock type

Open XL C/C++ 2.1 for z/OS has changed to use long long to implement std::chrono::file_system_clock, which causes a binary compatibility issue with Open XL C/C++ 1.1 for z/OS.

You must recompile all source code that uses std::chrono::file_system_clock, std::filesystem::file_time_type, or the std::filesystem::last_write_time() function with Open XL C/C++ 2.1 for z/OS.

Passing and returning complex types with non-empty base classes (C++ only)

When your source files contain complex types with non-empty base classes, the classes are passed and returned differently in Open XL C/C++ 2.1 for z/OS and Open XL C/C++ 1.1 for z/OS. C++ objects that are built with Open XL C/C++ 2.1 for z/OS might not be binary compatible with the C++ objects that are built with Open XL C/C++ 1.1 for z/OS. You should recompile the source file that provides the definition and all the source files that make use of the declaration with Open XL C/C++ 2.1 for z/OS.

C++ objects with statically initialized members

Open XL C/C++ 1.1 for z/OS might build object files that cause Language Environment® to fail to locate constructors that are used for static initialization.

Object files that are built by Open XL C/C++ 1.1 for z/OS with this issue are binary compatible with object files that are built by Open XL C/C++ 2.1 for z/OS. Object files that are built by these two compilers can even bind and run without error. However, it is possible that future changes to the binder might cause errors. Therefore, it is recommended to recompile all C++ source files that contain statically initialized members with Open XL C/C++ 2.1 for z/OS to avoid this issue.