Bug 1445370

Kevin, it seems that the email communication you attached to this ticket does not contain any details regarding the initializer ordering change you observed, and the reproducers (not attached to this bug) are concerned with the size change of debugging information.

Note that the C++ language does not define a global initialization order between different files.  Only within a single translation unit, global initialization is ordered according the the source file order.  However, GNU C++ has an extension, init_priority, which allows you to influence the global initialization ordering:

  https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html

The change was not mentioned in the Red Hat Enterprise Linux 7 release notes because the initialization order of different object files was already unspecified in Red Hat Enterprise Linux 6.  The ISO C++ standard states that initialization of these objects is indeterminately sequenced.  Depending on any particular ordering results in unspecified/undefined behavior.

Reordering of initialization was already possible in previous versions of Red Hat Enterprise Linux depending on compiler/linker options, ordering of files on the link line, and potentially other factors. It is unfortunate that the upgrade exposes a latent bug in your codebase, but this is the natural result of relying on unspecified behavior.

If you want to avoid the init_priority attribute and use a portable approach, you could replace the global variable xbfDG with a function like this:

xbfGlobalData &
xbfGlobalDataGet()
{
    static xbfGlobalData gd;
    return gd;
}

This way, the initialization will be performed as needed, upon the first reference to the object. Other global objects in your codebase may need similar treatment. (The GNU compiler implementation is thread-safe.)

Regarding the ability to run applications compiled on Red Hat Enterprise Linux 6 on Red Hat Enterprise Linux 7, Red Hat strongly recommends that application developers validate that any behavior they depend on is explicitly defined in formal API documentation and appropriate language standards to prevent introducing dependencies on unspecified implementation-specific semantics or introducing dependencies on bugs in a particular implementation.