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
0x922360B0.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
