Runtime Link-Loader Behavior and ODR (Is this a Bug?)

[Jeffrey Walton <noloader at gmail dot com>]

I have a few questions regarding ABI, ODR, and the Runtime Link-Loader.

Here's the scenario that Crypto++ was taking bug reports on when
maintainers decided to start packaging Crypto++ as a DSO.

==========


            +----- Some Plugin/DSO 1 -----\
            |                              \
apache -----+                                +----- Crytpo++ DSO
            |                              /
            +----- Some Plugin/DSO 1 -----/

* (best viewed with fixed font)

==========

Crypto++ DSO declares a global C++ class which has a destructor. Call
it g_Global. g_Global is declared once in Crypto++, and storage is
allocated for it
Crypto++ DSO .

Apache, Some Plugin/DSO 1, and Some Plugin/DSO 2 do not
declare it and do not provide a storage allocation for it.

==========

Apache loads Some Plugin/DSO 1. The constructor for g_Global is executed.
Apache loads Some Plugin/DSO 2. The constructor for g_Global *IS NOT* executed.

==========

Apache unloads Some Plugin/DSO 1. The destructor for g_Global *IS* executed.
Apache unloads Some Plugin/DSO 2. The destructor for g_Global *IS*
executed. <== Crash*

* (Crash might occur while Some Plugin/DSO 2 runs since the object has
been yanked out from under it. But it will surely occur on destruction
due to a double free)

==========

A reasonable/sane choice was made for the constructor. If a
reasonable/sane choice was made for the destructor, Crypto++ and
countless others would not have a crash.

==========

Where did Crypto++ violate ODR? Crypto++ provided one declaration, and
one definition. Period.

Why are the constructors not being executed twice?

Why are the destructors not being executed once?

==========

Unacceptable (two bugs)

(1) Since behavior for construction and destruction differ, (I expect
one behavior or another), I claim there is a bug in the runtime
link-loader.

(2) The runtime link-loader's handling of two Intermediate DSOs
including a common DSO is faulty. Its readily apparent that the
runtime link-loader cannot handle a flat namespace - which it created
in the first damn place (perhaps due to the ABI). I claim this is a
bug also.

==========

Acceptable (with one bug)

(1) Apache, Some Plugin/DSO 1, Some Plugin/DSO 2, and Crypto++ *each*
declare and allocate storage for g_Global, and its [miraculously] of
the same type. The runtime link-loader folds the symbols according to ODR.
(2) One constructor for g_Global
(3) Four destructors run on g_Global

The crash due to (3) is not a bug since its documented (RTFM).
However, the behavior regarding (2) and (3) is clearly broken - I
expect one behavior or another; and not a split of the behavior.

Jeff