D Library Breakage

[Jonathan Marler]

On Friday, 13 April 2018 at 23:36:46 UTC, H. S. Teoh wrote:
> 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.

You've missed part of the solution. The solution doesn't require 
you to compile with the same flags, what it does it takes the 
flags that were used to compile the modules you're linking to and 
interprets their "import source code" the same way it was 
interpreted when it was compiled.

If the precompiled module was compiled with the debug version, 
the `version(debug)` blocks will be enabled in the imported 
module source code whether or not you are compiling your 
application with debug enabled.  This guarantees that the source 
is an accurate representation of the precompiled library you'll 
be linking to later.

By the way...you're right that C/C++ suffer from the same 
problems with header files :)