On 6/21/2015 12:03 PM, Yaron Keren wrote: > >I still get errors because libwinpthread-1.dll cannot be found even > > The system PATH needs to include the directory where these DLLs are or > you can copy them to the directory where the compiled application resides.
I appreciate the free mingw-64 releases as well as the predecessor mingw releases so I will try to be as civilized in my response as I can. So here goes: 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. All the initial exes and dlls are in this directory. The Windows search order for DLLs tells me that the DLL should be found automatically if it is in the same directory as whatever module loads it. The whole point of a self-enclosed distribution is that one should not have to do any tricks, such as setting a PATH variable, for the distribution to "just work". If I have multiple mingw-64 distributions having to add the bin directory of each one to the PATH before I use that distribution is just as bad as having to have a c:\mingw directory link pointing to the one I execute. The correct design of mingw-64 ( or mingw ) would have me only execute the correct gcc and/or ld in the directory of the distribution to compile/link a program, without having to do anything further. > > > > 2015-06-21 18:28 GMT+03:00 Edward Diener > <eldlistmaili...@tropicsoft.com > <mailto:eldlistmaili...@tropicsoft.com>>: > > On 6/21/2015 2:28 AM, Yaron Keren wrote: > > The mingw-builds distro uses relative paths had worked well in any > > install location for the past two years at least. > > > > >http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/ > > > > It also includes the absolute path of the build original location but if > > not there it's ignored as nonexistent directory. It owuld be nice if > > this won't happen but not critical. > > I am not seeing what you have described. If I completely remove c:\mingw > I still get errors because libwinpthread-1.dll cannot be found even > though it is clearly part of the mingw-64 gcc 5.1.0 distribution I am > using to compile/link a program. Once I create a symbolic directory link > from c:\mingw to the place where my 5.1. mingw32 directory has been > installed everything works without problems. > > > > > 2015-06-21 5:44 GMT+03:00 John E. / TDM > > <tdra...@tdragon.net > <mailto:tdra...@tdragon.net> > > <mailto:tdra...@tdragon.net > <mailto:tdra...@tdragon.net>>>: > > > > On 6/20/2015 8:25 PM, Edward Diener wrote: > > > Thanks ! I will look at your toolchains. I assume if all paths are > > > relative there is no need for any installation to go into or have > a > > > symbolic link from c:\mingw. > > > > Correct. > > > > > Any timeframe for a gcc 5.1 release ? I noticed the latest > mingw-64 > > > install now has gcc-5.1, but it has the same hardcoded to c:\mingw > > > limitation which my OP is about. > > > > There may or may not be a TDM-GCC 5.1 release (5.1 being the first > in > > the GCC 5 series); right now I try to track the second minor > release in > > every major series, so expect TDM-GCC 5.2 at some point in the next > > month or two after the upstream 5.2 release. > > > > My experience in the past with other GCC toolchains was that they > tended > > to have enough usable relative search paths that you could still > move > > them around wherever you want, as long as you didn't put *anything* > at > > the hardcoded locations (/mingw or the like). That said, I haven't > tried > > this with a MinGW-w64-based toolchain other than my own in a while. ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
