On 20.06.2015 19:21, Edward Diener wrote: > 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.
gcc has a POSIX-centric (and complex) buildsystem. Hardcoding sysroot paths is not considered a deadly sin there. -- 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
