On 09/04/12 20:32, Peter Rockett wrote:
> From my point of view, the difference is between writing a program on a
> machine on which the MinGW toolchain is installed, and deploying a
> program on a machine on which MinGW is not installed. For the former, a
> static build is pointless. For the latter, a static build is, IMHO, a
> clean way of producing an program with no additional dependencies.
> There's the faff of copying the DLLs across in addition to the EXE - OK
> , a minor chore
We have build systems to take care of this; part of the coding phase is
to configure the build system, to automatically include the requisites
in the distributable package. If your "minor chore" entails anything
more than adding the DLL names to an appropriate namelist, then your
build system design is probably flawed; I certainly wouldn't describe
this as a "faff".
> but I have had users delete DLLs because they thought they were not
> needed. (Program stopped working - doh!)
Oh, sorry. I forgot that Windows is the OS of choice for clueless
idiots ... which is in no way intended to imply that present company
falls into this category.
> So unless it's a native system DLL, my view is that it's unwise to
> (dynamically) link against it for _deployable_ versions of programs.
You are entitled to that POV, as I am to disagree.
> But maybe that's my particular compartmentalised way of looking at
> the world...
> So I don't think it's fair to say "irrational aversion" - quite the
> opposite. But you may not agree with the rationale.
I don't; see below.
On 10/04/12 07:22, Eli Zaretskii wrote:
>> Date: Tue, 10 Apr 2012 06:15:38 +0800
>> From: JonY
>>> From my point of view, the difference is between writing a program on a
>>> machine on which the MinGW toolchain is installed, and deploying a
>>> program on a machine on which MinGW is not installed. For the former, a
>>> static build is pointless. For the latter, a static build is, IMHO, a
>>> clean way of producing an program with no additional dependencies.
>>> There's the faff of copying the DLLs across in addition to the EXE - OK
>>> , a minor chore but I have had users delete DLLs because they thought
>>> they were not needed. (Program stopped working - doh!) So unless it's a
>>> native system DLL, my view is that it's unwise to (dynamically) link
>>> against it for _deployable_ versions of programs. But maybe that's my
>>> particular compartmentalised way of looking at the world...
>>> So I don't think it's fair to say "irrational aversion" - quite the
>>> opposite. But you may not agree with the rationale.
>> I still think it's irrational, Windows people have a weird preference
>> for static linking.
> Which now makes _you_ sound "irrational", because, unlike your
> opponents, you gave no rationale whatsoever for your views.
Perhaps you didn't notice, but it was I who made the original throw away
statement, that I considered the aversion shown by many Windows users to
dynamic linking, to be irrational. JonY is a third party, declaring his
agreement with my POV; it isn't his place to defend my rationale -- it
is mine, and I have no problem in explaining it.
Peter's rationale is that he aims to protect the clueless idiots from
their own PEBKAC. That's fine, in principle, but where do you stop?
The problem with clueless idiots is that they tend to be ingenious
beggars; protect them from one manifestation of their folly, and they
will find another way to confound you. Better, by far, to educate them,
so that they can rise out of the mire of clueless idiocy.
Insisting on static linking may introduce further problems of its own.
For me, as a DLL developer, it may not be a huge additional overhead to
distribute a static equivalent, but to do so imposes a responsibility on
me, which I am unwilling to accept: by linking statically against my
library, you incur a moral responsibility to your users, that you will
update their copies of your distribution, should I release a critical
bug fix shortly after you publish. While you may be willing to accept
that moral responsibility, I will not allow you to delegate it upward,
to me. Had you linked dynamically, as I will always recommend, then the
maintenance burden would be reduced to dropping the updated DLL
into the end users' installations.
A further problem with static linking, particularly when you distribute
multiple executables all linked against a common library, is code size
of the distributed binaries. We went through this phase, before we had
mingw-get up and running, when we started to deliver i18n enabled
packages -- every executable had its own private, statically linked,
copies of libiconv and libintl, and the distribution was *huge*. We had
several complaints about that; users wanted i18n, but they hated the
associated code bloat. Today, we link dynamically, let mingw-get handle
the dependencies, and the code bloat is gone; everyone is happy.
All the above aside, the overarching rationale for me stems from the
queries we regularly used to field, (mostly in the days of GCC-3.x),
where users wanted to know how to avoid linking their threaded code with
the MinGW threading DLL. The answer, of course, is that they couldn't,
because that DLL was required to service a DLL hook to clean up the
thread pool on thread termination, (and in particular, to call the
destructors for the thread specific exception handler objects in C++
applications). We know of no other way to service this, other than via
a DLL hook; a static library simply will not suffice, (and this is still
the case today, although the clean-up code is now furnished by a DLL
supplied by the GCC folks). Nevertheless, a number of users were
reluctant to accept this, wasted many hours in futile attempts to find
an alternative (static) solution, and continued to bug us about their
failing efforts ... just to avoid distributing a tiny DLL, which has
never been encumbered by any distribution restriction. If that isn't
"irrational aversion", I don't know what it is.
So no, for me static linking is *not* the way to go, unless I have a
very solid technical reason for adopting it; avoidance of PEBKAC isn't
an adequate justification.