DIP45: fixing the dllimport/dllexport issue

[Martin Nowak]

On 09/07/2013 02:47 PM, Benjamin Thaut wrote:
>
> If you compile lib1 into a static library and then copmpile lib2 into a
> DLL which statically links against lib1 both symbols lib1Func and
> lib2Func will be exported from the dll because lib1Func will get marked
> as dllexport when compiled into a static library and the static library
> transports that information into the linking process of lib2. This
> happens both on win32 and win64. But this is something you really don't
> want. Lets imagine you have a DLL that statically links against phobos.
> Suddenly you will have all phobos exported symbols in your dll. This can
> also lead to double defined symbols in case a user links against your
> dll and against the shared phobos dll. So we have to fix this somehow.

I had another thought about this and tried some examples.

If you do transitively link against lib1.lib symbols when using lib2.dll 
you might get ODR issues if there is another copy of lib1 in your 
process. This is to be expected because there are two copies of the same 
library. The safe choice is to make lib1 a DLL too.

If you still want to statically link lib1 into lib2.dll you have to be 
very cautious. An actual problem only occurs when lib1 symbols get used 
from outside of lib2.dll.
Of course a mean to prevent bugs from accidental linking lib1 symbols 
would be nice.
One way of doing this would be to mark all lib1 symbols as PRIVATE in 
lib2.def.

EXPORTS
D4lib18lib1FuncFZi PRIVATE

Another way would be to write a small tool that turns all exported 
symbols of a library into non-exported symbols.

I'm not sure we should do this in the compiler, because it simply hands 
over the libs to the linker. We'd have to make a copy of the library 
first and then do what a tool would do.

Another note for the phobos case. You should really ask yourself why 
does your dll need a private copy of phobos. And if so why can phobos 
symbols leak out of your dll.