D Library Breakage

[Jonathan Marler]

Currently phobos is going through a transition where DIP 1000 is 
being enabled.  This presents a unique problem because when DIP 
1000 is enabled, it will cause certain functions to be mangled 
differently.  This means that if a module in phobos was compiled 
with DIP 1000 enabled and you don't enable it when compiling your 
application, you can end up with cryptic linker errors that are 
difficult to root cause.

This problem has exposed what I think to be a deeper problem with 
the way D handles precompiled modules. Namely:

Precompiled D libraries do not expose the "important compiler 
configuration" that was used to compile them.  "Important 
compiler configuration" meaning what versions were used, whether 
unittest was enabled, basically anything that an application 
using it needs to know to properly interpret the module the same 
way it was interpreted when it was compiled.

For example, say you have a library foo with a single module.

module foo;

struct Foo
{
     int x;
     version (FatFoo)
     {
         private int[100] y;
     }
     void init() @safe nothrow
     {
         x = 0;
         version (FatFoo)
         {
             y[] = 0;
         }
     }
}

Now let's compile it:

dmd -c foo.d

Now let's use it:

import foo;

int main() @safe nothrow
{
     Foo foo;
     foo.init();
     return 0;
}

dmd main.d foo.o   (foo.obj for windows)
./main             (main.exe for windows)

It runs and we're good to go.  Now let's do something sinister...

dmd -version=FatFoo -c foo.d

Now compile and run our program again, but don't include the 
`-version=FatFoo`

dmd main.d foo.o   (foo.obj for windows)
./main             (main.exe for windows)

We've just stomped all over our stack and now it's just a pancake 
of zeros!  Your results will be unpredictable but on my windows 
box main throws an exception even though the function is marked 
@safe and nothrow :)

The root of the problem in this situation comes back to the 
problem that DIP 1000 is currently having.  The "important 
compiler configuration" used to compile our library is unknown.  
If we could take our precompiled library foo.o and see what 
compiler configuration was used to compile it, we wouldn't have 
this problem because we would have seen it was compiled with the 
"FatFoo" version.  Then we would have interpreted the module we 
used to load it with the "FatFoo" version and avoided this 
terrible "pancake stack" :)

So what do people think?  Is this something we should address?  
We could explore ways of including information in our 
pre-compiled libraries that the compiler could use to know how it 
was compiled and therefore how to interpret the modules the same 
way they were when being compiled.  All object formats that I 
know of support sections that tools can use to inject information 
like this. We could also just tell people that they must make 
sure to use the same compiler configuration for their own 
applications that were used when their libraries were compiled.  
If they don't ensure this then all safety guarantees are 
gone...not ideal but less work for D right? :)