DIP45: fixing the dllimport/dllexport issue

[Benjamin Thaut]

Am 10.09.2013 05:39, schrieb Martin Nowak:
>>> I also kind of feel that we need to export lib1 as well, as you may not
>>> know what lib2 does with what it gets from lib1 (passing objects around
>>> for instance). So certainly at least some part of lib1 need to be
>>> exported.
> For sure lib2 might forward to some lib1 symbols.
> Not sure what might accidentally require linkage.
>
>> I don't agree if that statement. If you have three libs. lib1, lib2 and
>> lib3. And lib2 and lib3 link statically against lib1 you are going to
>> get linker errors because both lib2 and lib3 contain the symbols of lib1.
>
> A: Why do two DLLs which export the same symbols cause linker errors?
Yes
> Because the corresponding import libraries contain the same symbols?
> B: You shouldn't mix static with dynamic linking, ODR issues are what
> you get in return.
Well you should not. But it will happen. Espeically if you don't have 
any control over what others due. E.g. when using third party libraries.

> C: What would happen if you statically link against lib2 and lib3?

Well you would get a linker error as well. But the reasoing behind this 
is as follows.

You use a third party library that comes as a shared library. That third 
party library uses say libcurl internally. Now you use libcurl too. You 
link against libcurl. But because the third party library you link to 
also uses libcurl you will get linker errors. Also you might not want to 
use the same version of libcurl then the thirdparty library you use. 
This is going to become a problem especially in bigger projects, where 
you are not able to compile the third party libraries yourself because 
you don't have the source code. In such a case it can easily happen that 
you get a new version of that third party library, they added a new 
internal dependency to a library you already use and suddenly your 
executable won't linke anymore.

Kind Regards
Benjamin Thaut