>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.
I misunderstood you, thought you refer to running compiled apps not gcc. It's very convenient to have the gcc bin directory on the PATH as you can run gcc from any directory location without typing the full path, but that should not be required. When running gcc.exe the all DLLs is the gcc.exe directory should be found without any PATH modifications. 2015-06-21 19:56 GMT+03:00 LRN <lrn1...@gmail.com>: > On 21.06.2015 18:56, Edward Diener wrote: > > On 6/21/2015 7:45 AM, LRN wrote: > >> On 21.06.2015 5:44, John E. / TDM wrote: > >>> On 6/20/2015 8:25 PM, Edward Diener wrote: > >>>> 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. > >>> > >>> 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. > >>> > >> > >> This is correct. Windows versions of gcc are fully relocatable (and were > >> for years), the only problem you'll encounter with unpatched (or > >> poorly-configured) gcc build is that anything in <current > >> drive>\mingw\(include|lib) (or whatever the hardcoded path ends up > pointing > >> at) will be used by gcc (which is usually not what you want). > > > > It is not correct in my testing. If I don't have a c:\mingw but try to > > compile/link uisng a mingw-64/mingw32 installation directly I get an > > error message saying that a dll ( libwinpthread-1.dll ) can not be found > > even though it is in the same directory as the compiler and linker. With > > a c:\mingw directory I do not get this error. > > That's a new one. > > Please provide your directory layout for your toolchain, location of the > libwinpthread-1.dll as well as the contents of PATH environment variable at > the moment when you run compiler/linker. > > > 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. > > I think it should be noted that back when i still used MSVC, Microsoft > *did* modify PATH when running Visual Studio, and they have a "developer > command prompt", which is just a batch file that sets up environment > variables and starts the command prompt. > > As for why this might not work in case of gcc, i can't tell you exactly, > but gcc does consist of multiple executables, and not all of them reside in > the bin subdirectory. Try adding bin subdirectory to PATH, see if anything > improves. > > -- > O< ascii ribbon - stop html email! - www.asciiribbon.org > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > >
------------------------------------------------------------------------------
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
