DIP45: fixing the dllimport/dllexport issue

[Rainer Schuetze]

On 12.09.2013 01:16, Martin Nowak wrote:
> 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.
>

This sounds interesting. Stripping an existing library isn't even needed 
because it is normally never created with exports anyway (-lib implies 
that no exports are created to start with). Stripping object files might 
be necessary, though, in case they have been built separately with -c.