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. > 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
