DIP45: fixing the dllimport/dllexport issue

[Benjamin Thaut]

Am 08.09.2013 06:19, schrieb deadalnix:
> On Saturday, 7 September 2013 at 21:41:01 UTC, Benjamin Thaut wrote:
>> I don't agree if that statement. If you have three libs. lib1, lib2
>> and lib3. And lib2 and lib3 link statically against lib1 you are going
>> to get linker errors because both lib2 and lib3 contain the symbols of
>> lib1. And you don't have any options to avoid that (unless you got
>> into the source of lib1 and remove all export attributes, which might
>> not even be possible because you don't have the source)
>
> And you should have an error, especially is you pass object from one
> side to the other.
>
> typeid won't match (which will create a mess in the runtime), and worse,
> struct layout may not match (hello memory corruption).
>
> If the problem is that big, we can still have a -noexport flag or
> something, but that doesn't seems really safe to me.

But only assuming that you are passing around objects of that type. I 
see a dll as a module of encapsulation. If the library is only unsed 
internally nothing of its dependencies should get exported. Because if 
they are your users might rely on the fact that they are, and from that 
point on you have to garantuee that all those additional exported 
functions from your dependencies stay in your library, even if you don't 
need the dependency anymore.