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.