Solaris Direct Binding For Shared Libraries May Cause Fortran Runtime System Errors
(Doc ID 1904375.1)
Last updated on MARCH 01, 2019
Applies to:Oracle Solaris Studio - Version 12.3 to 12.3 [Release 12]
Information in this document applies to any platform.
F90 8.6 (Oracle Solaris Studio 12.3) on Solaris.
A shared library is built using direct binding (-Bdirect).
Memory is allocated inside of the shared library, and then deallocated in the main application outside of the shared library.
Example error message:
Error 1222: deallocating an object with a different type than it was allocated with
Location: the DEALLOCATE statement at line 17 of "hello.f90"
Abort (core dumped)
The problem occurs only when -Bdirect is used to build a shared library, and the same objects are then accessed inside and outside of that shared library.
The problem does not occur with the March 2014 beta compilers (or newer).
The Solaris OOF (object oriented Fortran) implementation generates global symbols to represent the derived types used in OOF contexts. For the application to work correctly,
these symbols have to remain global in all shared libraries where they are used. However, if a user creates a shared library and uses a map
file which turns those compiler-generated symbols into symbols local to the shared library, or if he uses direct binding on a shared library (-Bdirect), then the shared
library and the executable might not use the same definitions for the same derived types, and that will lead to incorrect runtime results.
This document handles the case where direct binding on a shared library is used (-Bdirect). It does not apply to the scenario where a map file is used
which turns compiler-generated symbols into symbols local to the shared library.
In Fortran 8.6, the default is -singleton=no.
In Fortran 8.7, the default is -singleton=yes, and thus the qoption is not needed.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document