DIP45: fixing the dllimport/dllexport issue

[Rainer Schuetze]

On 11.09.2013 00:39, Martin Nowak wrote:
> 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
>

That's probably not feasible for a library like phobos. (At least 
optlink stumbles if the def file gets too large). Also, compressed 
symbol names cause troubles for OMF.

> 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.
>

AFAIU the discussed scenario is that the phobos library exports a lot of 
symbols, and this library is used both for static and dynamic linking. 
An executable statically linked against this library will have all the 
exports. That still works but is ugly.

A DLL to be used as a plugin with a C interface might also want to link 
statically against phobos to avoid DLL hell. Consider multiple plugins 
built against different versions of phobos. These would also leak also 
the symbols.