|
From: Earnie B. <ea...@us...> - 2012-04-13 13:38:40
|
On Fri, Apr 13, 2012 at 6:11 AM, Greg Chicares wrote:
> 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
Thanks for the work and follow-up. My opinion is yes, the required
DLL should exist in the disparate directories to accommodate the
disparate application executables. Once Keith has post-install
scripts working for mingw-get we could just do a copy into the
appropriate directories. Until then the package should contain a
duplicate DLL.
--
Earnie
-- https://sites.google.com/site/earnieboyd
|