https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123976
--- Comment #126 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Sergey Fedorov from comment #124) > (In reply to Peter Dyballa from comment #120) > > (In reply to Iain Sandoe from comment #119) > > > additional: > > > > > > To bootstrap, i used a GCC-10.5 built using Apple gcc-4.2.1 > > > > It does not play a role which compiler is used to start building since in > > the end it's GCC that builds its final stage. So I won't start building > > GCC-10. And I am not sure which compiler was used to start building > > GCC-15.2, could be GCC-7 I then had and used since MacPorts' default > > compiler for this job or port had failed a few times. > > While I believe the statement in the narrow context is correct (provided gcc > build has succeeded), what is problematic is that once environment diverges > from what was tested, there is no way to know what could have affected the > failing build. > We know, for example, that a few specific ports do break the build of gcc. > What we don't know is whether all other do not have that effect. > > P. S. BTW, if you build outside of *Ports, make sure to set the PATH so that > /opt/local/bin is NOT in it. (Alternatively, all ports are deactivated.) > Otherwise we are back to the same problem: arbitrary binaries can be picked. agreed if adding the PATH to the bootstrap compiler enables a whole bunch of other tool changes - once again we are in the "too many variables" land...
