Re: libgmp-10.dll not found

by Peter Rockett :: Rate this Message:

On 10/04/12 13:42, Earnie Boyd wrote:

> On Mon, Apr 9, 2012 at 3:32 PM, Peter Rockett<p.rockett@...> wrote:
>> On 09/04/12 10:16, Keith Marshall wrote:
>>
>> ...snip
>>>> Ultimately, the cleanest technique would be static linking... but
>>>> unfortunately MinGW does not provide static libraries.
>>> Well, that isn't likely to happen; (why do so many Windoze users exhibit
>>> this irrational aversion to using DLLs?)
>>>
>> 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 for one disagree with your arguments and agree with Keith. Users
> who go deleting files in a programs directory without understanding
> the side affects are to be lined up against the wall, blindfolded and
> shot. Really, they are at their own mercy and should not be allowed
> near a computer. If one is stupid enough to delete a dll file then
> they are also stupid enough to delete the .exe file so your excuse for
> your rational doesn't stand the test of stupidity.

Trying to account for the deletion of DLLs is not really the issue here,
dumb though it may be.

> Using a DLL cuts the memory foot print when more than one copy of the
> program is in memory or more than one program uses the same functions.

Very true. But I am talking about deployment where it is highly likely
that only one program will be using an 'alien' DLL at any one time. The
following arguments about waste of memory, paging etc. then fall by the
wayside. Unless a DLL is being used by more than one process at a time,
surely the arguments in favour of DLLs become much less clear? Faster
linking in development? But that's not a deployment issue. And
convenience of updating packages.

Out of interest, I am not clear on the strategy an OS takes when one of
the DLLs it has loaded is no longer required by any process. I would
guess that it may unload the DLL to recover the memory. In which case, I
suspect that on the vast majority of systems, MinGW DLLs are only ever
used by a single process at any one time and then unloaded. So are the
lower memory usage arguments theoretical in most cases? Or does the DLL
stay put once loaded until explicitly removed? Just curious...

> Using static versions of those libraries causes multiple copies of
> the same functions to be in memory in different locations at the same
> time. Using static versions of libraries cause the users computers to
> become slower because now memory must be swapped out more often. So,
> yes it is fair to say "irrational aversion" because you haven't given
> a solid reason to use a static library.

Surely if there's no advantage to be gained from using a DLL (cos it
will only be used by one process), the only thing left is the 'negative'
of creating a dependency and possibly conflicts if two DLLs are mapped
to the same address. Let me be clear: Using DLLs is best in most
situations but in some (rare?) situations, a static lib is better
because the performance is no different and you do not have to worry
about dependencies.

And aren't DLLs slower because the entry point to the function has to be
found by indirection? But I wouldn't suggest that as a serious reason
not to use DLLs... :-)

P.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe

« Return to Thread: (no subject)