Re: [boost] [build] guru needed: static vs dynamic lib conundrum for serialization/filesystem library

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.

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