D Library Breakage

[Jonathan Marler]

On Friday, 13 April 2018 at 10:47:18 UTC, Rene Zwanenburg wrote:
> On Friday, 13 April 2018 at 05:31:25 UTC, Jesse Phillips wrote:
>> Well if DIP1000 isn't on by default I don't think Phobos 
>> should be compiled with it.
>>
>> I think that the version issue is not unique to D and would be 
>> good to address, but I don't see the compiler reading the 
>> object file to determine how it should built the import files.
>
> More importantly, it can be perfectly valid to link object 
> files compiled with different options. Things like parts of the 
> program that shouldn't be optimized, or have their logging 
> calls added/removed.

One thought I has was that we could define a special symbol that 
basically encodes the configuration that was used to compile a 
module.  So when you import a precompiled module, you can insert 
a dependency on that special symbol based on the configuration 
you interpreted the imported module with with.  So if a module is 
compiled and imported with a different configuration, you'll get 
a linker error.

If we take the previous example with main and foo.

compile foo with -version=FatFoo

foo.o contains special symbol (maybe 
"__module_config_foo_version_FatFoo")

compile main without -version=FatFoo

main.o contains dependency on symbol "__module_config_foo" (note: 
no "version_FatFoo")

link foo.o main.o

Error: symbol "__module_config_foo" needed by main.o is not 
defined

The linker error isn't great, but it prevents potential runtime 
errors.  Also, if you use the compiler instead of the linker 
you'll get a nice error message.

dmd foo.o main.o

Error: main.o expected module foo to be compiled without 
-version=FatFoo but foo.o was compiled with it