Edward,
I'm really flashed about the enormous patience and tolerance from this
community.
However, you may or may not noticed, that there are different builds with
configurations for mingw-w64 based toolchains available.
What you need for your purpose is a toolchain that is based on statically
linked gcc runtimes. That means, the binaries build by the compiler do not
depend on the runtime DLLs delivered by the toolchain.
What comes into my mind is:
TDMs toolchain: http://tdm-gcc.tdragon.net
and equation.com:
http://www.equation.com/servlet/equation.cmd?fa=programminglog
I didn't test the fully relocability of these toolchains itself (without
setting the PATH) , but the compiled binaries are self-contained. This
procedure is not recommened for C++ programming with heavy use of
exceptions though, because exceptions can't be propagated across DLL
boundaries (TDM's toolchain has patches to allow this AFAIK). My own set of
builds of the toolchain are more targeted to the needs of python extension
development but may be of interest too: see
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwpy-2015-04-readme.pdf
And you are free to build the mingw-w64 based gcc toolchains yourself and
offer patches.
Carl
2015-06-22 20:15 GMT+02:00 Edward Diener <eldlistmaili...@tropicsoft.com>:
> On 6/22/2015 12:02 PM, Óscar Fuentes wrote:
> > Edward Diener <eldlistmaili...@tropicsoft.com>
> > writes:
> >
> >>> Apparently those programmers are not so inconvenienced as you are by
> >>> having to use methods like the .bat mentioned above. And I can assure
> >>> you that some of those programmers have quite a few gcc installs on
> >>> their machines, that they use on a regular basis.
> >>
> >> You are much better than the original mingw installations but your
> >> reliance on having to set the PATH rather than have a direct invocation
> >> work correctly is a real PITA.
> >
> > 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.
> 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.
>
> >
> >>> >From what I recall, Visual Studio is even worse on this regard, as it
> >>> requires setting some environment variables with paths to work. That's
> >>> what vcvars32.bat does. How do you deal with multiple VS installs from
> >>> the command line? Or you just use the IDE? I'm succesfully using the
> >>> .bat method described above for multiple installs of VS and Mingw-w64.
> >>
> >> As my beloved mother used to say when I was a kid, "Just because your
> >> friend Johnny wants to jump off the top of the Empire State building
> >> does that mean you have to do it too?"
> >
> > That's not an answer to my question: how do you deal with multiple
> > installs of VS? (I'm sure you have several of them, unless you use
> > multiple machines, one for each)
> >
> > To recap: what you are experiencing is not a consequence of oversight or
> > lazyness from the MinGW(-w64) developers, but the less annoying solution
> > for the problem of installing one or more MinGW(-w64) instances without
> > causing havoc.
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
