On 6/22/2015 4:50 PM, Óscar Fuentes wrote: > Edward Diener <eldlistmaili...@tropicsoft.com> > writes: > >>> As I mentioned on other message on this thread, you must set PATH >>> anyways for executing the resulting binaries of your compilation. There >>> is no possible workaround for this, other than installing libwinpthread, >>> libstdc++ and co. on a directory that already is on PATH. But that would >>> preclude having more than one MinGW(-w64) installed on your system, >>> among other problems. >> >> You mention this as if it were some law of programming. Once again >> just because the relationships of modules ( exes and dlls ) are setup >> poorly in mingw-64 distros does not mean that this is the only way >> things could be. I have already explained that if you have all modules >> which need to reference each other in the same directory then some >> module finding another module will happen automatically in Windows. >> This would allow for self-enclosing distributions of mingw-64 which >> does NOT need the ridiculous nonsense of putting some bin directory in >> the PATH. You could distribute as many distros as you like and if they >> were all self-enclosing in the way I have mentioned you don't ever >> need the PATH environment variable set to any one distro's bin >> directory at any time. > > Maybe your frustration does not allow you to understand what I wrote. > Please read it again. I expect some difficulty with the concept of > having multiple installs of the toolset, with varying versions and > configurations, but there is no excuse for not understanding the point > about the generated executables depending on the same (and more) dlls > that cc1plus.exe depends on. Unless you pretend to emit your executables > to the same bin directory where those dlls are, the cleanest solution is > to add the bin directory to PATH. Yes, they could install cc1plus.exe on > the same bin directory where g++.exe is. That would make you happy (at > the cost of making others miserable) until the moment you realize that > you need to set PATH anyways.
Please explain to me why I would need to "set PATH anyways" to a particular toolchains bin directory if the dlls needed by any particular executable in a toolchain were in the same directory as the executable itself. > >> Claiming otherwise to me, who am a programmer with a pretty good >> understanding of how modules work under Windows, is futile unless you >> want to ram down my throat the information that this is the way mingw-64 >> does things and we are not going to change. If so I already got that >> message. But claiming that you can't technically do it better, just >> because the idiots at Microsoft are the example which you choose to >> follow, is utter nonsense and I am pretty sure that if you are a >> programmer yourself you must know that. > > The model that MinGW(-w64) follows does not depend on what MS does or > doesn't. But the fact that both toolsets have similar requirements wrt > setting environment variables (with MinGW being the simplest, BTW) does > tell us something about the space solution for the general problem. ------------------------------------------------------------------------------ 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
