D Library Breakage

[Jonathan M Davis]

On Friday, April 13, 2018 16:15:21 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 4/13/18 3:47 PM, Jesse Phillips wrote:
> > On Friday, 13 April 2018 at 18:04:38 UTC, Jonathan Marler wrote:
> >> 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
> >
> > The issue I have here is that Main doesn't need to be compiled with the
> > versions defined by its dependents.
> >
> > So if someone defines a version list in their dub.sdl then all those
> > versions need to be defined in my dub.sdl when in reality I don't care
> > and just want to link to the library with those versions defined.
>
> Yes, the problem is that the tool is too blunt. We really only need to
> worry about version differences when the layout is affected. When the
> symbols are affected, it won't link anyway. This is the issue with the
> dip1000 problems.
>
> It's perfectly natural or normal to have version statements only affect
> implementation, which are fine to link against without worrying about
> the versions defined.
>
> I don't know if the compiler can determine if a version statement
> affects the layout, I suppose it could, but it would have to compile
> both with and without the version to see. It's probably an intractable
> problem.

Also, does it really matter? If there's a mismatch, then you'll get a linker
error, so it's not like you're going to get subtle bugs out of the deal or
anything like that. I don't see why detection is an issue here.

The real issue is how we deal with a switch that's intended to allow us to
transition from one behavior to another when it causes linker errors. A
switch where the behavior change is contained within a library isn't a
problem, but a switch that effects the API such that it won't even link
anymore if the switch isn't consistently used or not used doesn't really
give us a transition path. As it stands, -dip1000 can't really be properly
tested, because no one can use it if they're using Phobos, since Phobos
isn't compiled with -dip1000, and if we compile it with -dip1000, then
everyone is forced to use -dip1000, making it a pointless switch. As it
stands, it looks like we're in a situation where -dip1000 won't ever be
particularly usuable - at least not for anyone who doesn't compile Phobos
themselves. And in that case, we practically might as well have just changed
the behavior to the default with a particular version of the compiler rather
than having a transition switch. Much as the switch is supposed to help us
make the transitition from one behavior to another, it completely falls flat
on its face with regards to providing a clean way to transition. What we
need to figure out is how to make it so that it can actually function as a
transitional switch.

- Jonathan M Davis