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 :)
