Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Issues of compiling VisiBroker C++ application in different operating platforms

Issues of compiling VisiBroker C++ application in different operating platforms

[[Traps and Pitfalls in VisiBroker Application Development | Back]]


In this article, we will use Linux as the operating platforms to explain the issues in details. However, users are advised that the information given is applicable to the rest of the operating systems as well. If not, undesirable consequences would occur if one were not careful, as we shall explain in the following.

Building a user application under the VisiBroker for C++ 8.5 product with the user own customized build script to target any operating systems platform can give unwelcome surprises if one does not discern the differences of the compilation directives contained within the file stdmk that shipped with the product installation under the examples directory.

The C++ compiler directives contained in the file stdmk for a particular operating platforms are unique and specific in order for the product to work on that operating systems. It is also contained the directives on what are the product features are supported. It will varies from one operating platforms to another. Therefore, it is paramount that the product user extracts the compiler directives content from the file stdmk and use it exactly in their build script in order for the application to work correctly at runtime.

Beside the compiler directives, the C++ include headers that shipped with the 32-bit product version may slightly different from the 64-bit product version. For an example, the data type “_VIS_LONG_DOUBLE”, it is supported on the 64-bit Linux platforms but not for the 32-bit version. The features configuration generated for a particular product version is stored in the vopt.h header file. Therefore, it is another important factor to consider when the users build the application to generate either 32-bit or 64-bit binaries. The include header directories location in the users build script need to adjust accordingly.

We have incidents reported on the user application source build using the VisiBroker 64-bit product installation under the Linux platforms to generate a 32-bit binary showed an abnormal memory usage growth at runtime. Another is a crash dump phenomena. If the same application source were to rebuild with the 64-bit binary target, it would run perfectly fine.

The 64-bit Linux installation includes the 32-bit library binaries to assist the migration of the existing 32-bit VisiBroker user application. The goal is to ease the deployment of both 32-bit and 64-bit applications using one installation.

The VisiBroker on Linux developers would like to make use of one 64-bit product install and achieve the benefit to continue to develop the 32-bit or the 64-bit application. However, the compilation of 32-bit C++ application source cannot achieve using the 64-bit product install. The reason is that the shipped C++ include headers are targeted specifically toward the 64-bit Linux platforms.

As an example, VisiBroker supports one of the data type “_VIS_LONG_DOUBLE” depending on the operating platforms. There are additional virtual member functions API generated to support operations for this data type. For the Linux platforms, the 64-bit product is included this feature but not in the 32-bit version product.

In the one of the shipped header mbuf.h, you could see that additional virtual member functions are enabled only if the “_VIS_LONG_DOUBLE” type is supported:

class _VISEXPORT CORBA_MarshalInBuffer: public VISistream, private VISResource
#if defined(_VIS_LONG_DOUBLE)
    virtual VISistream& operator>>(long double&);

#if defined(_VIS_LONG_DOUBLE)
    virtual VISistream& get(long double *, unsigned size);

The implication is that the user 32-bit application compiled directly using the C++ include headers from the 64-bit Linux installation would generate a different object map size. Specifically, the object vtable size at the user application layer would be larger than the one shipped in the VisiBroker 32-bit libraries. When an object memory is created at the user application layer and passed to the VisiBroker layer to manage the memory, leak would occur. The object size created at the user application layer is larger than what the 32-bit VisiBroker layer would see. Therefore, when the 32-bit VisiBroker binary runtime freed the memory, only the 32-bit size, the extra segment region created for the 64-bit size will not managed by the memory manager.

This inconsistency causes the generated binaries at the user application level to become incompatible with the shipped VisiBroker binaries. Hence, the unexpected runtime behavior like memory keeps growing; or a virtual member function at the application layer called into an incorrect vptr table entry in the VisiBroker layer causing a crash dump.

Alternative form that could lead to such binary incompatibility is that the user has injected the compiler directives for the VisiBroker feature such as "_VIS_LONG_DOUBLE" which available only for the 64-bit Linux into the user build script that target the 32-bit binary generation. Therefore, please watch out for the additional VisiBroker directives in your user build scripts that are not specified in the file stdmk that is shipped with the product.

Therefore, the solution is to continue to build the 32-bit Linux applications using the VisiBroker 32-bit product install. The compiled application can still be tested and deployed using the 32-bit libraries from the 64-bit installation.


[[Traps and Pitfalls in VisiBroker Application Development | Back]]


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Version history
Revision #:
1 of 1
Last update:
‎2013-08-20 08:28
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.