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. > > Back when i still used mingw.org, they had /mingw path hardcoded and would > therefore suck up anything in <currentdrive>\mingw\(include|lib). This > is/was a widely-known bug. > > Many builds (especially of Mingw-w64) hardcode (again, hardcoding is not > intentional, it's a side effect of the build process that no one bothers to > try to eliminate) an absolute DOS path to a directory that is unlikely to > exist, thus sidestepping the issue this way. > > My solution, which eliminates the problem completely (AFAICS) was outlined > earlier. Other builds may have something similar going as well. > > What you see as an archaic engineering feat that should be fixed as a bug > is actually a quirk of a very complex non-Windows-oriented buildsystem of a > piece of software that is very strict on what changes are accepted > (especially to the buildsystem), who are they accepted from (you need to do > a copyright assignment to contribute to gcc) and how they are vetted. > This is just not worth bothering with for anyone who knows what the problem > is. Fixing it on a per-build basis is easy enough. > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > 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
