On 2012-04-09 12:15Z, Earnie Boyd wrote:
> On Fri, Apr 6, 2012 at 6:47 PM, Greg Chicares <
[hidden email]> 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
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2_______________________________________________
MinGW-users mailing list
[hidden email]
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-usersAlso: mailto:
[hidden email]?subject=unsubscribe
Locked
