On 6/22/2015 8:17 PM, Óscar Fuentes wrote: > Edward Diener <eldlistmaili...@tropicsoft.com> > writes: > >>> 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. > > Ok, I'll try with different wording: > > Do you plan to create your executables in the bin directory of the > toolchain? Surely not. As those executables compiled by you will depend > on the same dlls that cc1plus.exe et al. depend on, you need to add the > directory that holds those dlls to PATH (or copy them to the directory > that holds your executable.)
You have made a good point, but see my subsequent answers... My usage of mingw-64 might be to only compile, or to compile/link, without the need to run anything immediately. > > So moving cc1plus.exe to `bin' makes the toolchain "self contained", but > it is no solution as soon as you try to execute the programs you created > with that toolchain. One of the most favored methods of doing what you suggested is to copy whatever dlls are needed by the module created into the same directory where the module was created. This is no different from my suggestion that the same thing be done with a mingw-64 toolchain. But however I decided to do things it should be up to me to make that decision and not up to mingw-64 to create their own toolchain so that I am forced to add some toolchain's bin directory to my PATH just to compile and/or link my module. Furthermore with multiple toolchains your method of adding the toolchains bin directory to the PATH is asking for problems. What happens after I finish my compile/link cycle and test my program from within some batch file created simply for that purpose by temporarily putting some mingw-64's toolchain's bin directory in my PATH. I now go to run my program and the temporary addition to my PATH is gone and my program refuses to start. Now I have to go back and work out which mingw-64 toolchain created the program and which dlls I need from that toolchain. Clearly I am not going to add multiple toolchain bin directories to my PATH permanently, since any given module will now be picking up its dlls from the first toolchain bin directory in my PATH, which may not be the dlls that I need. In fact the whole business of adding any compiler toolchain's bin directory to the PATH permanently is a recipe for disaster. And if you think that the correct way to actually permanently execute my program is to do so from a batch file so that the correct toolchain's bin directory is in the PATH you are in a programming world which I am all too glad never to want to enter. I am not saying there is no place in programming where installing the latest same-named, totally backward compatible dll into a directory permananently in the PATH has its value. But that place is not multiple mingw-64 toolchains with their proliferation of dlls for compile and/or run-time use. I do understand why you say that the toolchain's bin directly may need to be added to the PATH in order to run my program directly after the compile/link cycle. But I would still heavily prefer that mingw-64 create their toolchains so that I can compile/link my program without having to manipulate the PATH variable in any way. Once I finish compile/link of my module(s) how I choose to ensure that the needed modules are in the correct place to run my program should be up to me. ------------------------------------------------------------------------------ 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
