D Library Breakage

[H. S. Teoh]

On Fri, Apr 13, 2018 at 11:00:20PM +0000, Jonathan Marler via Digitalmars-d wrote:
[...]
> @JonathanDavis, the original post goes through an example where you
> won't get a compile-time or link-time error...it results in a very bad
> runtime stack stomp.

To put things in perspective, this is essentially the same problem in
C/C++ as compiling your program with one version of header files, but
linking against a different version of the shared library.  Well, this
isn't restricted to C/C++, but affects basically anything that uses the
OS's dynamic linker.  It's essentially an ABI change that wasn't
properly reflected in the API, thus causing problems at runtime.

The whole thing about sonames and shared library versioning is
essentially to solve this problem.  But even then, it's not a complete
solution (e.g., I can still compile against the wrong version of a
header file, and get a struct definition of the wrong size vs. the one
expected by the linked shared library).

Basically, it boils down to, "don't make your build system do this".


[...]
> The point is, this is a solvable problem.  All we need to do is save
> the compiler configuration (i.e. versions/special flags that affects
> compilation) used when compiling a library and use that information
> when we are interpreting the module's source as as an "pre-compiled
> import".  Interpreting a module with a different version than was
> compiled can create any error you can possibly come up with and could
> manifest at any time (i.e.  compile-time, link time, runtime).

The problem with this "solution" is that it breaks valid use cases.  For
example, a shared library can have multiple versions, e.g., one compiled
with debugging symbols, another with optimization flags, but as long as
the ABI remains unchanged, it *should* be valid to link the program
against these different versions of the library.

One example where you really don't want to insist on identical compiler
flags is if you have a plugin system where plugins are 3rd party
supplied, compiled against a specific ABI.  It seems impractically
heavy-handed to ask all your 3rd party plugin writers to recompile their
plugins just because you changed a compile flag in your application
that, ultimately, doesn't even change the ABI anyway.


> The jist is that if we don't solve this, then it's up to the
> applications to use the same versions that were used to compile all
> their pre-compiled D libraries...and if they don't...all bets are off.
> They could run into any error at any time and the compiler/type system
> can't help them.

Linking objects compiled with different flags, in general, is not
recommended, but in the cases where you *do* want to do that, it's
essential that you *should* be able to choose to do so, without running
into the red tape of the compiler playing nanny and stopping you from
doing something that "might" "possibly" be dangerous.


T

-- 
Help a man when he is in trouble and he will remember you when he is in trouble again.