On 6/20/2015 10:50 AM, LRN wrote: > On 20.06.2015 17:43, Edward Diener wrote: >> Why does mingw-64, or the original mingw for that matter, consistently >> hardcode include and lib search paths in their build for c:\mingw >> instead of searching for include files and libraries relative to its >> installation structure ? > > This is a side-effect of the way gcc is built. It's possible to mitigate > this by > 1) Cross-compiling gcc (instead of compiling it on Windows) from Cygwin or > a GNU system > 2) Patching gcc to throw away include and lib paths that start with '/' > when running on Windows. > > If not cross-compiled, gcc will have an absolute DOS path in its search > list (this is mitigated by building it in a randomly-named staging > directory deep in the temp tree to ensure that this has near-zero > probability of acting up in real life); some people settle for that.
Thanks for the info. I guess the question then is why gcc is built in such backwards ( to this programmer ) way. Hardcoding absolute paths, in programing circa the year 2015, seems abolutely lunacy. But I don't expect an answer to why gcc works the way it does on this mailing list. ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
