https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jack Howarth from comment #5) > (In reply to Iain Sandoe from comment #3) > > > > > 3. I don't see why GCC should be subject to the vendor's support policy. As > > far as I am concerned, with the right SDK / sysroot available, there's no > > reason why a compiler *hosted* on x86-64-Darwin18 shouldn't be able to build > > code for i686-darwin10 *target*. > > That makes the assumption that the cctools in some future macOS release > won't obsolete out the code for support i386 assembly and linkage. I > wouldn't be surprised if that actually happened should Apple start making > arm64-apple-darwin a thing. We are not dependent on the Xcode supplied tools for some time now, since upstream dsymutil is functional. So, if that were to happen - we would simply (as the Linux folks do) build a complete toolchain rather than just the compiler (i have a 'cctools' look-alike driver for the LLVM backend - and an actual cctools assembler with the known bugs fixed). To assist this, it would be helpful if fink, macports etc. could file radars noting that the open source releases are very out of date for these components (currently 8.2.1 compared with the released Xcode of 10.x)
