https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #38 from Arsen Arsenović <arsen at gcc dot gnu.org> --- (In reply to cqwrteur from comment #35) > Unless the "old enough glibc" won't be able to build latest GCC. Even glibc > 2.25 (which is centos stucks with). File a bug or write a patch. I'm not sure how you'd expect libraries to be forwards compatible - this is not magic. > Unless system distributed one is not an option for a lot of reasons. > 1. Old enough glibc won't be able to build latest GCC > 2. The machine itself is very slow to the point to unable to build gcc. For > example Raspi. > 3. The environment itself stucks for many reasons to the point of unusable. > Like building GCC directly on windows natively. > 4. Convience perspective. Testing MSVC, GCC and clang at the same time, > testing GCC cross compilers. The best way is to build cross back compiler > and use it on windows so that I can compile all the code on windows. > > > mingw has nothing to do with things here. it is a cross compiler. It has > nothing to do with sysroot in mingw. There is no need for sysroot at all. MINGW is required to build Windows programs, AFAIK (note that I've never built a Windows program..), at least due to the headers. This implies that the headers (and probably libraries) need to be in the sysroot of the to-Windows cross-compiler. This does not seem avoidable. (In reply to cqwrteur from comment #36) > Also, it is a waste of energy and time to build the same compiler on > different machines over and over again instead of just building one, > packaging it and distributed it among many machines. Plus Cloud servers has > storage usages quotes to the point of unable to do so. I agree - that's why I build binary packages of my Gentoo system. There is at least one other approach that I suggested (building once with an old glibc in some odd prefix).
