Re: [Mingw-users] Question: libgmp-10.dll not found?

[Greg C. <gch...@sb...>]

On 2012-04-09 12:15Z, Earnie Boyd wrote:
> On Fri, Apr 6, 2012 at 6:47 PM, Greg Chicares <gch...@sb...> wrote:
>> On 2012-04-06 17:23Z, Marcus Szanto wrote:
>>>
>>> I am getting an error when running g++.exe. The error is "The program
>>> can't start because libgmp-10.dll is missing from your computer. Try
>>> reinstalling the program to fix this problem.".
>>> I have libgmp-10.dll in the bin folder, yet it still is getting that
>>> error. Any idea?
>>
>> Is the compiler's bin/ directory on the PATH?
> 
> It doesn't have to be if the .exe and dependent .dll is in the same
> directory.  Windows by default looks in the directory the program is
> executed from for any dependent startup .dll.

We expect dlls to be found that way, yet g++ at first appears not to
meet that expectation. Having dug into the issue now, I believe I can
explain what's going on and suggest a fix.

First, to reproduce the issue that the OP reports, I install MinGW
gcc afresh, using 'mingw-get-inst-20111118.exe' (the latest), into
F:\MinGW-20111118\ . I use CMD.EXE to rule out any MSYS effect, and
I do *not* change %PATH%. When I invoke g++ with its full path:

C:\tmp>type C:\tmp\hello.cpp
#include <iostream>
#include <ostream>
int main() {std::cout << "Hello, world!" << std::endl;}
C:\tmp>F:\MinGW-20111118\bin\g++ C:\tmp\hello.cpp

it fails, and a messagebox appears:
  cc1plus.exe - Unable To Locate Component
  This application has failed to start because libgmp-10.dll was not found.
  Re-installing the application may fix this problem.

Has g++ failed to find 'libgmp-10.dll' even though both reside in
the same bin/ directory? No. The title of the messagebox identifies
the program that couldn't find that dll: not g++, but 'cc1plus.exe'.
And that program isn't in bin/; it's here:
  F:\MinGW-20111118\libexec\gcc\mingw32\4.6.1\cc1plus.exe
but the dll is in bin/, with g++, the program that *spawned* cc1plus.
And the OS's dll search looks in the directory of the program that's
running--not of the program that spawned it.

If I copy
  libgmp-10.dll       (required by cc1plus.exe)
  libmpc-2.dll        (required by cc1plus.exe)
  libmpfr-1.dll       (required by cc1plus.exe)
into F:\MinGW-20111118\libexec\gcc\mingw32\4.6.1\ (where 'cc1plus.exe'
resides), and
  libgcc_s_dw2-1.dll  (required by as.exe)
  libiconv-2.dll      (required by as.exe)
  libintl-8.dll       (required by as.exe)
into F:\MinGW-20111118\mingw32\bin (where 'as.exe' resides), then the
test case above works as originally hoped. (There's another copy of
'as.exe' in bin/, but apparently g++ or cc1plus invokes the one in
mingw32/bin/ .)

Should that copying be done in the MinGW distribution? Already there
are 7.4 MB of copied .exe's in mingw32/bin/, and the six dlls above
add up to an extra 1.9 MB; that would make a C++ installation only
one percent larger. The benefit is that invoking the compiler driver
(by its fully-qualified filename, like 'F:\MinGW-20111118\bin\g++')
will just work, with no PATH change required. That's handy if you're
switching between different versions, and safer, too, in this case:
  PATH=F:\MinGW-20111118\bin;%PATH%
  F:\MinGW-20111118\bin\g++ foo.cpp
  # ...an unexpected error occurs, so back up one version
  F:\MinGW-20110802\bin\g++ foo.cpp
  # ...oops, that uses the newest version's dlls