DIP45: fixing the dllimport/dllexport issue

[Martin Nowak]

On 09/11/2013 08:21 AM, Rainer Schuetze wrote:
> 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.

Yes and it also has some runtime/memory overhead because the symbol 
table is much bigger.

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

Right, that's the valid use-case. But here the additionally exported 
symbols are way less of a problem because your loading not linking.
And as I wrote before if you link a program with two copies of the same 
library you're asking for trouble.

Anyhow I realized there is even less a use-case for statically linking a 
lib into a DLL (shared library) while expecting the symbols to be 
exported. We use that to put druntime into libphobos2.so though.
Also one doesn't need exported (visible) symbols for static linking.

So how about going into the opposite direction?
When the compiler creates a lib it strips all the exports (marks all 
symbols as hidden) by default. For the very special use-case where one 
wants to preserve the exports we can add a -libexports flag, only to be 
used with -lib.
Another nice thing is, that dmd writes libs itself and already processes 
all object files so we could easily integrate the striping in the compiler.