Subject: Re: [boost] [build] guru needed: static vs dynamic lib conundrum for serialization/filesystem library
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-08-04 14:40:58
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk