On 6/21/2015 8:22 PM, Óscar Fuentes wrote: > Yaron Keren <yaron.ke...@gmail.com> > writes: > >>> Why in the world should I have to put anything in my PATH if these >>> releases are self-enclosed ? I am executing gcc from the exact same >>> directory where the libwinpthread-1.dll exists. >> >> I misunderstood you, thought you refer to running compiled apps not gcc. >> >> It's very convenient to have the gcc bin directory on the PATH as you can >> run gcc from any directory location without typing the full path, but that >> should not be required. When running gcc.exe the all DLLs is the gcc.exe >> directory should be found without any PATH modifications. > > Please note that gcc.exe/g++.exe are just drivers that invoke the actual > compiler, linker, etc. For example, in my MSYS2 install, cc1plus.exe > (the C++ compiler) is in lib/gcc/i686-w64-mingw32/4.9.2 directory. When > you invoke g++.exe, it runs cc1plus.exe. Since it is in another > directory, the Windows rules for locating dlls will not succeed at > finding libwinpthread-1.dll because it is not in the same directory as > cc1plus.exe. > > Ironically, placing the real compiler, linker, etc on their own > directory hierarchy is done, precisely, for making possible the > coexistence of multiple versions and/or configurations. This work > correctly on Linux and other Posix-like systems, because core > dependencies like libwinpthread-1 (or its equivalent on Linux) are > installed on a place that guarantees that the system will find it, and > properly versioned. The correpondent procedure on Windows would be to > install libwinpthread-1.dll on %WINDIR%/System32, with a versioning > based on a naming schema (as Linux does) or using whatever Windows > provides for keeping multiple versions of dlls (WinSxS?). In practice > this requires a centralized authority or distribution point to work > correctly, something that the MinGW(-w64) community lacks. > > At the end, adapting your PATH setting works the best. Just a simple > .bat file solves the problem for those of us that need to constantly > experiment with multiple installs: > > @rem mingw-w64-492.bat > @PATH=path-to-the-bin-directory;%PATH% > @%* > > > Now invoke that .bat with > > mingw-w64-492.bat g++ foo.cpp -o foo.exe > mingw-w64-492.bat foo.exe
Sure, but the point is that this should never be needed. The easiest solution is that any dll that cc1plus.exe needs should have been installed in the same directory as cc1plus.exe. Your other solution of putting the needed dlls in %WINDIR%/System32 is not very good unless all versions of such dlls are backward compatible since each new installation of mingw-64 might have its own version of a dll. I am surprised that such good programmers should understand so little about producing a self-enclosed installation of mingw-64 ( or mingw ) to the point of not being able to create a distribution that just works automatically when any executable, such as gcc, is invoked directly from the command line. ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
