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.
