Vladimir Prus wrote:
On 03.08.2012 21:53, Robert Ramey wrote:
BUT the dll created, as well as the serialization library used have been created with static linking.
Do you mean static runtime linking? By definition, dll cannot use static linking.
Hmmm - I'm not seeing this. I can create a DLL which statically links with other code - just as I can create any other executable which statically links with other code.
Never the less, users do this and I want to test it.
I believe that using static runtime from DLL, is something that should never, ever, be done.
From my stand point - a DLL is just another kind of executable. An advantage of this would be that the DLL is self contained and doesn't start a chain of depencies on other DLLs which might not be the same versions - aka DLL hell.
Of course doing this risks creating another kind of hell. Different statically linked DLLS could contain different versions of the same functions from other libraries like the C standard library - basically violations for the ODR rule. and it's worse for functions like strpos which create static data within the modules which define them.
On Linux, it was possible years ago via tricky command line options, but is no longer possible. On Windows/MSVC, this may be still possible, but unless I am entirely wrong, this is extremely risky practice that should not be promoted.
I'm not really interested in promoting the practice - but I'm more inclined to tolerate it and to recognise that it happens in practice sometimes for good reasons - the lessor of two evils.
So, unless some MSVC expert steps in and proves me wrong, I think this is not use case that need to be supported or tested for in the first place.
I would like to be able to test it. Bjam has no objection. I think it's just a case where some detail in the file system auto linking setup creates a conflicting set of macro definitions. One other thing - the test matrix doesn't doesn't reveal the build/bjam settings. I would like a page like this to automatically show whether it's been built debug/release, static/dynamic linking, runtime-linking etc. Perhaps this information could be added. Robert Ramey PS off topic don't read; The whole issue of runtime linking/ODR/versioning, etc, etc. has been an afterthought in C++ and programming languages in general. This has lead to fiascos like COM - I don't know about CORBA. But its a huge interesting question for the future. I've seen the C++ proposal for modules. I don't know if they are intended to address this but resolving this "problem" will likely result in a whole new generation of languages. And I believe that program/services in the future will be built be composition of more disparate parts - which is supported today in only an adhoc manner. RR