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.
