[build] guru needed: static vs dynamic lib conundrum for serialization/filesystem library
The serialiation library uses the boost.filesystem component in it's tests. On tests which test dlls on windows I'm getting an error: test_dll_exported.cpp ..\..\..\boost\filesystem\config.hpp(69) : fatal error C1189: #error : Must not define both BOOST_FILESYSTEM_DYN_LINK and BOOST_FILESYSTEM_STATIC_LINK call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat" >nul cl /Zm800 -nologo @"..\..\..\bin.v2\libs\serialization\test\test_dll_exported.test\msvc-7.1\debug\link-static\threading-multi\test_dll_exported.obj.rsp" Which I've traced to the command line "test_dll_exported.cpp" -Fo"..\..\..\bin.v2\libs\serialization\test\test_dll_exported.test\msvc-7.1\debug\link-static\threading-multi\test_dll_exported.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /Wp64 /GB /Op /wd4675 /EHs -Gy -wd4996 -c -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS "-I..\..\.." which is produced by BJAM. The test application creates a DLL which is part of the test. BUT the dll created, as well as the serialization library used have been created with static linking. I'm assuming that the file system library is also created this way. I "think" this should be OK even though some C++ runtime code will be repeated between the DLL and the mainline test components and that this might create a problem so it's probably not the best practice. Never the less, users do this and I want to test it. I believe that the problem resides in some thing in the BJAM files related to filesystem libraries or test but I've been unable to track it down further than the above. Any help would be appreciated. Robert Ramey
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.
I'm assuming that the file system library is also created this way. I "think" this should be OK even though some C++ runtime code will be repeated between the DLL and the mainline test components and that this might create a problem so it's probably not the best practice. 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. 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. 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. - Volodya
On Sat, Aug 04, 2012 at 10:59:18AM +0400, 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.
I'm assuming that the file system library is also created this way. I "think" this should be OK even though some C++ runtime code will be repeated between the DLL and the mainline test components and that this might create a problem so it's probably not the best practice. 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. 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.
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.
In the Boost case, no, there's no real use case for disjoint runtimes in different modules. In the real world, less so. It is perfectly sound to have dynamic libraries built with different runtimes as long as you're aware that you may never share any built-in C++ or C types across the module boundary, and make sure that anything you allocate in one module, you destroy with the functions in that module. A very common use case for such a thing is plugin architectures for applications that have enough of a legacy baggage to have it's own "standard library"-like library implemented, with cross-module safe types. I write such code all the time. Like anything else, it's about recognizing the restrictions and limitations you have in a situation, but saying it's "by definition" is doing a disservice as it _isn't_ impossible, it's just very cumbersome. -- Lars Viklund | zao@acc.umu.se
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
participants (3)
-
Lars Viklund -
Robert Ramey -
Vladimir Prus