On 8/31/2011 10:08 PM, JonY wrote:
> On 8/31/2011 21:54, Charles Wilson wrote:
>> On 8/31/2011 5:48 AM, JonY wrote: Hmm. don't know what the
>> correct (mingw[64]) solution for this would be. In the past, when
>> the C++ ABI changed, we didn't bump the libstdc++ DLL number,
>> because so many other things ALSO break (in precompiled C++
>> clients), that just isolating ONE change via the DLL number of
>> one runtime lib was pointless. I suspect that is true here,
>> too.
>>
>
> Not bumping the number would also be problematic for precompiled
> code using the old ABI, I was thinking the old dll be made
> available via mingw32-libstdc++-6-compat-1 DLL only package.
My point is, the ABI of the underlying C++ runtime library is
invariably exposed by the (C++) client DLLs -- unless their interface
is pure C. So, if you have a stack of C++ dlls with the following
dependency
APP.EXE
libfoo-1.dll
libbar-2.dll
libbaz-3.dll
libstdc++-6.dll
libstdc++-6.dll
libbaz-3.dll
libstdc++-6.dll
libstdc++-6.dll
libstdc++-6.dll
If you "bump" the DLL for libstdc++-6.dll (so that "old" clients can
continue to use it, via some -compat package, and the new gcc packages
ship libstdc++-7.dll), this will require you to "bump" the DLL number
of ALL of the clients, when they are recompiled to use the new
runtime. (And, of course, each of those CLIENT dlls will ALSO have to
ship a -compat package to provide the old dll with its old dllnum). If
you don't do this for the clients, then your "stack" will break
because some are using libstdc++-7 and some are using libstdc++-6, and
their definitions for, say, new[] or std::string are different.
Oh, and if you DO bump the DLL numbers of all the clients, then you
can't really compile APP.EXE (which depends on all those client DLLs)
until you finish recompiling the whole stack (and bumping all their
dllnums) anyway...
Now, this massive bump-and-compat headache is /technically/ the
correct procedure. From a /practical/ standpoint, however, I'll point
you here:
http://www.cygwin.com/ml/cygwin-apps/2009-03/msg00033.html
where you can read Yaakov's rant on changing the DLL number of giant
stacks of interdependent DLLs on a single platform, due to a platform
specific ABI change, and how horrid it makes life for maintainers ON
that platform *forever* after. (Esp. with regards to dlopen() and/or
LoadLibrary())
In that discussion, I was on the other side at the time; I've come
'round to Yaakov's view -- which is: sure, if the ABI changes badly
enough in the underlying runtime, all the client DLLs will break until
recompiled. That's bad, but the alternative is WORSE, so you do a
flag day, and publish updated versions of all the known client DLLs at
the same time the new runtime is released.
As it happens, on cygwin there are (a) so few C++ dlls, and (b) even
the ones we have are so rarely used, that we did NOT do a flag day,
and yet...nobody noticed. Eventually all the C++ clients were
recompiled...
The considerations from the POV of mingw[org,64] might be different
than from cygwin, of course.
> Of course, talk is easy, implementing it would be another problem,
> since libstdc++ is so integrated into GCC.
Ack.
--
Chuck
